release: commit state on which containers are built #1203
Merged
Conversation
This file contains 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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously, we would build both container images and cli on a dirty state: we bumped the flake version to release but didn't commit it, the build the container images, then commit the updated cli assets, then build the cli on the still dirty state, as the flake version bump still wasn't committed. This made reproducing the release very difficult.
With this patch, we are committing the flake version bump to the release, too. This produces a first commit (flake bump to release), on which we build the container images, and a second commit (cli assets) on which we build the cli.
Another problem not fixed with this release is that the tag of the release points to the last commit (flake bump to next -pre), but that is difficult to mitigate at this point (we could do it on the release branch transaction, but that should be minimal as there isn't a way to test it). Also there isn't a "correct" commit to point the tag to, as we build release artifacts from the two different commits as mentioned above.