ci: revert file changes and add some checks #12873
Conversation
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
lgfa29
added
backport/1.0.x
lgfa29
requested review from
DerekStrickland,
tgross,
a team,
shore and
jeanneryan
.github/workflows/release.yml
Outdated
| - name: Revert notification channel | ||
| if: ${{ github.event.inputs.notification-channel != '' }} | ||
| run: | | ||
| sed -i.bak -e 's|\(notification_channel * = *"\)[^"]*|\1${{ steps.notification-channel.outputs.prev-channel }}|g' .release/ci.hcl | ||
| rm -rf .release/ci.hcl.bak | ||
| git diff --color=always .release/ci.hcl |
There was a problem hiding this comment.
We're calling this "revert" but it's not obvious whether this literally backing out "Generate files for..." commit or making a slightly different change that could potentially drift. Could we literally reset this file with git (ex. git reset $ref -- .release/ci.hcl)?
This is particularly the case for the step below too, where we're doing two different things.
There was a problem hiding this comment.
Ah yeah, good point. This one is direct revert, the next one not quite, so I will rename it as well. Thanks!
After looking at the different release options and steps I noticed that automatic CHANGELOG generation is actually the exception, so it would be better to have the default to be false.
There was a problem hiding this comment.
Apologies in advance if I'm asking a question that doesn't make sense.
Since we have conditional logic based on branch (I think?) could we use an approach similar to what is discussed here so that we don't have to manually massage files? I'm sure you already considered something like this. I'm just trying to learn more about the context / challenge.
I didn't quite follow that. The conditional logic is based on the prerelease part of the version being release. The only branch check we have is to prevent it from running from Is this what you had in mind? |
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
|
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
During the release there are several files that need to be modified:
channel with greater team visibility during the release.
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
next version number.
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should never run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.