This repository was archived by the owner on Sep 9, 2026. It is now read-only.
Repository navigation
Conversation
Our integration tests were failing with Go 1.25.5:
Downloading sigs.k8s.io/controller-tools/cmd/controller-gen@v0.16.1
# golang.org/x/tools/internal/tokeninternal
../../../go/pkg/mod/golang.org/x/tools@v0.24.0/internal/tokeninternal/tokeninternal.go:64:9: invalid array length -delta * delta (constant -256 of type int64)
make: *** [Makefile:249: /home/lars/redhat/innabox/cloudkit-operator/bin/controller-gen] Error 1
This was due to version skew between Go and controller-tools. This commit
updates controller-tools to 0.17.1, which resolves this incompatibility.
As long as we're updating things, let's bring all dependencies up-to-date using `go get -u`.
We have a bunch of integration tests that spin up an etcd and api-server,
and it's good that we have them, but they are unsuitable for running as
part of a pre-commit hook (or in other situations in which a longer running
test can be disruptive).
This commit marks all integration tests with the `integration` build tag.
That makes it possible to run `go test ./...` and have it complete
successfully.
If you want to run the integration tests, you can run:
make test-integration
Or if you have the binary requirements already in place, you can run:
go test -tags=integration ./...
The e2e-tests are protected by the `e2e` tag. You can run them via:
make test-e2e
(This is unchanged, although we have modified the Makefile to use build
tags rather than `grep` to target specific tests.)
x-branch: feature/disable-e2e
Add a workflow that uses conventional commits [1] to automatically increment the version, and generate a new release on GitHub when there is a new version number. In short: - Commits prefixed with `fix:` will increment the patch version number (`v0.1.0 -> v0.1.1`). - Commits prefixed with `feat:` will increment the minor version number (`v0.1.0 -> v0.2.0`) - Commits that introduce a breaking change (typically signified with a `!` after the commit type, like `feat!:`) will increment the major version number. You can also introduce a breaking change by including a `BREAKING CHANGE:` footer in your commit message. We build a new container image on every push. For releases, we tag the image with the version number (and the minor version, and the major version, so `v0.1.1` will result in an image with tags `v0`, `v0.1`, and `v0.1.1`) and update the `latest` tag to point to the new image. Pushes that do not include any conventional commit tags will not generate a new release. [1]: https://www.conventionalcommits.org/en/v1.0.0/ x-branch: feature/release-workflow
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add a workflow that uses conventional commits 1 to automatically
increment the version, and generate a new release on GitHub when there is a
new version number.
In short:
Commits prefixed with
fix:will increment the patch version number(
v0.1.0 -> v0.1.1).Commits prefixed with
feat:will increment the minor version number(
v0.1.0 -> v0.2.0)Commits that introduce a breaking change (typically signified with a
!after the commit type, like
feat!:) will increment the major versionnumber.
You can also introduce a breaking change by including a
BREAKING CHANGE:footer in your commit message.We build a new container image on every push. For releases, we tag the
image with the version number (and the minor version, and the major
version, so
v0.1.1will result in an image with tagsv0,v0.1, andv0.1.1) and update thelatesttag to point to the new image.Pushes that do not include any conventional commit tags will not generate a
new release.
NB: This PR includes #93.