@@ -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

@@ -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:

@@ -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

@@ -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

@@ -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

@@ -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 `kubebuilder@googlegroups.com` with the subject `[ANNOUNCE] kubebuilder $VERSION is released`

@@ -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

@@ -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{

@@ -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