Implement release-start and release-go-images #49
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
Moving these funcs out of buildmodel represents their broad purpose better. But more importantly, it lets us reuse them without creating a dependency cycle between the buildmodel and sync packages.
This is where it belongs: it's specific to CI builds in AzDO. Moving it removes clutter from the releasego package and it may be used by other packages in the future.
The new funcs operate on a git directory. Using receivers on a struct is more complicated, and the struct's fields didn't apply nicely to all scenarios the funcs should be reusable in.
The PR number and up-to-date-commit variables need to be set by a handful of commands that interact with PRs in some way, so this is moved to the sync package.
Adds the option for dockerupdate/dockerupdatepr to set AzDO variables to PR number and/or up-to-date commit hash for pipeline automation. Fix change detection to work with submodules.
The final pipeline can use get-images-commit to wait for all PRs generated by each version's dockerupdatepr call to complete and merge.
The pipeline can use these to create one issue per version number to be built and one issue to track the combined release day.
dagood
commented
Jun 24, 2022
Update release-build to include go-images Docker update. Add release-go-start to kick off the release day, and release-go-images to join each individual version's build back into one job and finish off the release activity by running the Docker image release.
dagood
force-pushed
the
dev/dagood/release-image
branch
from
e588994
to
f32c03e
Compare
qmuntal
approved these changes
Jun 27, 2022
chsienki
approved these changes
Jun 28, 2022
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.
This PR fills in the beginning and tail of end-to-end release automation. This PR means that as long as the patch files don't require fixup, there are only three manual steps to take care of: run a build with a list of version numbers to release, approve the go-images build to start polling, and send an internal announcement email. There's still a bunch that can be improved (see the bottom of
docs/release-process/README.md) but the pipelines should already be more helpful than harmful. 😄 The improvements can be worked on incrementally.Rendered instructions: docs/release-process/instructions.md
Rendered main readme (includes general flow diagram): docs/release-process/README.md
I split the changes into commits to review one by one. There are a few refactors that should be a lot clearer this way, rather than showing up in various places in a big, combined diff. The commit messages include more info about each step.