Merge pull request kubernetes-sigs#2163 from kubernetes-sigs/master

🌱 update release-3 for v3.0.0

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -1,5 +1,5 @@
 name: Bug Report
-about: Problems and issues with code or docs
+description: Problems and issues with code or docs
 labels:
 - kind/bug
 body: 
@@ -126,7 +126,7 @@ body:
 
 - type: dropdown
   attributes: 
-    label: " "
+    label: "Extra Labels"
     description: |
       If this is *also* a documentation request, etc, please select that below.
     multiple: true

.github/ISSUE_TEMPLATE/config.yml

@@ -1,5 +1,5 @@
 # allow free form issues as an escape hatch.  This can be taken away if people abuse it ;-)
-blank_issues_enabled: true 
+blank_issues_enabled: true
 
 # link to CR and CT for easier access
 contact_links:

.github/ISSUE_TEMPLATE/feature_request.yaml

@@ -81,7 +81,7 @@ body:
 
 - type: dropdown
   attributes: 
-    label: " "
+    label: "Extra Labels"
     description: |
       If this is *also* a documentation request, etc, please select that below.
     multiple: true

CONTRIBUTING.md

@@ -95,8 +95,8 @@ separately.
 
 The docs are published off of three branches:
 
-- `book-v2`: [book.kubebuilder.io](https://book.kubebuilder.io) -- current
-  docs
+- `book-v3`: [book.kubebuilder.io](https://book.kubebuilder.io) -- current docs
+- `book-v2`: [book-v2.kubebuilder.io](https://book.kubebuilder.io) -- legacy docs
 - `book-v1`:
   [book-v1.book.kubebuilder.io](https://book-v1.book.kubebuilder.io) --
   legacy docs

Makefile

@@ -88,7 +88,7 @@ golangci-lint:
 ##@ Tests
 
 .PHONY: test
-test: test-unit test-integration test-testdata ## Run the unit and integration tests (used in the CI)
+test: test-unit test-integration test-testdata test-book ## Run the unit and integration tests (used in the CI)
 
 .PHONY: test-unit
 test-unit: ## Run the unit tests
@@ -119,3 +119,7 @@ test-e2e-local: ## Run the end-to-end tests locally
 .PHONY: test-e2e-ci
 test-e2e-ci: ## Run the end-to-end tests (used in the CI)`
 	./test/e2e/ci.sh
+
+.PHONY: test-book
+test-book: ## Run the cronjob tutorial's unit tests to make sure we don't break it
+	cd ./docs/book/src/cronjob-tutorial/testdata/project && make test

RELEASE.md

@@ -5,7 +5,7 @@ The Kubebuilder Project is released on an as-needed basis. The process is as fol
 1. An issue is proposing a new release with a changelog since the last release. You will need to use the [kubebuilder-release-tools][kubebuilder-release-tools] to generate the notes. See [here][release-notes-generation]
 1. All [OWNERS](OWNERS) must LGTM this release
 1. An OWNER runs `git tag -s $VERSION` and pushes the tag with `git push $VERSION`. Note that after the OWNER push the tag the CI will automatically add the release notes and the assets.
-1. A PR needs to be created to merge `release-X` branch into `book-vX` to pick up the new docs.
+1. A PR needs to be created to merge `master` branch into `book-v3` to pick up the new docs. 
 1. The release issue is closed
 1. An announcement email is sent to `[email protected]` with the subject `[ANNOUNCE] kubebuilder $VERSION is released`
 

VERSIONING.md

@@ -34,7 +34,7 @@ the latest controller-tools release.  That info is stored in
 ## Book Releases
 
 The book's main version (https://book.kubebuilder.io) is published off of
-the [book-v2][book-branch] (a version built off the main branch can be
+the [book-v3][book-branch] (a version built off the main branch can be
 found at https://master.book.kubebuilder.io).
 
 Docs changes that aren't specific to a new feature should be
@@ -43,7 +43,7 @@ The cherry-picks will automatically be published to the book once their PR
 merges.
 
 **When you publish a KubeBuilder release**, be sure to also submit a PR
-that merges the main branch into [book-v2][book-branch], so that it
+that merges the main branch into [book-v3][book-branch], so that it
 describes the latest changes in the new release.
 
 [book-branch]: https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases
@@ -57,7 +57,7 @@ the desired next version.  Once the PR is merged, Google Cloud Build will
 take care of building and publishing the artifacts.
 
 [envtest-ref]: https://book.kubebuilder.io/reference/artifacts.html
-[tools-branch]: https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases)
+[tools-branch]: https://github.com/kubernetes-sigs/kubebuilder/tree/tools-releases
 
 ## Versioning
 

docs/book/src/cronjob-tutorial/testdata/project/controllers/suite_test.go

@@ -115,14 +115,16 @@ var _ = BeforeSuite(func() {
 		The only difference is that the manager is started in a separate goroutine so it does not block the cleanup of envtest
 		when you’re done running your tests.
 
-		It is not recommended to use the manager client in tests because it is not strongly consistent. Indeed, the manager
-		client is designed to do the "right thing" for controllers by default which is to read from caches. The best solution
-		is to instantiate a new client using client.New for tests (as k8sClient above). It will provide a client that reads
-		directly from the API meaning that you can write tests expecting read-after-write consistency.
-
-		However, keep in mind that you should not do this in the controller's conciliation loop (read an object after you have
-		written it). Kubernetes favors an approach where you first do some reads, process and then do some writes and return.
-		This way, you let the queue take care of the next cycle of readings if they are necessary.
+		Note that we set up both a "live" k8s client, separate from the manager.  This is because when making assertions in
+		tests, you generally want to assert against the live state of the API server.  If you used the client from the
+		manager (`k8sManager.GetClient`), you'd end up asserting against the contents of the cache instead, which is slower
+		and can introduce flakiness into your tests.  We could use the manager's `APIReader` to accomplish the same thing,
+		but that would leave us with two clients in our test assertions and setup (one for reading, one for writing), and
+		it'd be easy to make mistakes.
+
+		Note that we keep the reconciler running against the manager's cache client, though -- we want our controller to
+		behave as it would in production, and we use features of the cache (like indicies) in our controller which aren't
+		available when talking directly to the API server.
 	*/
 
 	k8sManager, err := ctrl.NewManager(cfg, ctrl.Options{

test.sh

@@ -14,11 +14,6 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.
 
-source test/common.sh
-
-header_text "Running kubebuilder unit tests"
-go test -race -v ./pkg/...
-
-./test/integration.sh
-
-./test/testdata/test.sh
+# prow calls this file currently, but we can just use `make test` to test
+# the set of things we want.
+make test