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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change the release flow to use release branches #2253
Change the release flow to use release branches #2253
Changes from 15 commits
ca22c78
1d045ea
37bc560
a8a6ff2
219f125
9394c6b
6ee191d
9d997d1
8a8713a
9cadab2
93dcf7b
d163264
91b2978
63b3a56
aa2a7eb
cfea8dc
14c4118
99b6ece
f8de002
dd472e4
5dd621d
7841f53
e07e0cd
815ffc5
4851010
a439fc5
a318f04
42fc4fb
7751de1
3a52ed7
0414cce
e3c0bc2
9a739ba
c95e895
b7dab07
53bb4cc
7806c72
62e0518
2526b89
5b2fa2b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way we could check that the versions we will be publishing in
gradle.properties
aren't already published? Would be a nice sanity check that thegradle.properties
was correctly updated.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be quite cumbersome.
Things can fail at any step, including publishing - leaving us with some unpublished runtime crates. I'm opting for building the workflow in such a way that all steps are idempotent, therefore allowing us to retry any transient failure by re-triggering the workflow from the right commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider pulling this out to a separate shell script file so that it can be easily tested locally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in dd472e4
Shellcheck found a lot of issues 😅 Thanks for pointing it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What in
tools/
uses thegradle.properties
file? Doesn't seem like this should be necessary. Even if a tool readsgradle.properties
from the filesystem, it shouldn't need an updated Docker image since that version number isn't being compiled into the tool.Separately, you will probably want an escape hatch for using the latest tools in
main
for the actual release workflow since you may need an updatedpublisher
to actually successfully publish.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My assumption is that you can always merge the upgraded tools into the release branch if that's required, indeed as an escape hatch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SDK changelog entries need to end up in
aws/SDK_CHANGELOG.next.json
upon release so that the SDK changelog can be generated when it is released. It currently uses thechangelogger split
subcommand to accomplish this. Does this new release process preserve that?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - the
aws/SDK_CHANGELOG.next.json
will be on the release branch and it's generated in the previous step of the workflow.