Add workflow for rolling back release #3033
Conversation
mbg
force-pushed
the
mbg/ci/rollback-release
branch
2 times, most recently
from
f4f6c63 to
3376c74
Compare
…ges are available
mbg
force-pushed
the
mbg/ci/rollback-release
branch
from
7c91b1c to
67e42fe
Compare
| runs-on: ubuntu-latest | ||
| timeout-minutes: 45 | ||
|
|
||
| # Don't set the deployment environment for test runs |
There was a problem hiding this comment.
| # Don't set the deployment environment for test runs | |
| # Don't set the deployment environment for test runs | |
| # The Actions token does not have permissions to push changes to workflow files. | |
| # Since workflow files may change as part of a backport PR, we use the "Automation" environment for real runs to authenticate as a GitHub App and push these changes. |
|
|
||
| uses: ./.github/workflows/prepare-release.yml | ||
|
|
||
| rollback: |
There was a problem hiding this comment.
We'll soon be needing to release CodeQL Action v4 to run on Node 24. I think the backport automation in update-release-branch.yml would create necessary backport releases, but I think we might want a way to more quickly rollback a change across all active release branches (without waiting for the full set of PR checks). Perhaps it makes sense to matrix this job across all active release branches?
| git tag --annotate "${MAJOR_VERSION_TAG}" --message "${MAJOR_VERSION_TAG}" --force | ||
|
|
||
| - name: Push tags | ||
| if: github.event_name == 'workflow_dispatch' |
There was a problem hiding this comment.
| if: github.event_name == 'workflow_dispatch' | |
| # skip when testing | |
| if: github.event_name == 'workflow_dispatch' |
| run: | | ||
| git push origin --atomic --force refs/tags/"${RELEASE_TAG}" refs/tags/"${MAJOR_VERSION_TAG}" | ||
|
|
||
| - name: Prepare partial Changelog |
There was a problem hiding this comment.
I think it could be clearer what we mean here by "partial changelog". It's still not fully clear, but we could call it "release description" for instance?
| VERSION: "${{ needs.prepare.outputs.version }}" | ||
| GH_TOKEN: ${{ steps.app-token.outputs.token }} | ||
| run: | | ||
| # Do not mark this release as latest. The most recent CLI release must be marked as latest. |
There was a problem hiding this comment.
| # Do not mark this release as latest. The most recent CLI release must be marked as latest. | |
| # Do not mark this release as latest. The most recent bundle release must be marked as latest. |
| run: | | ||
| # Do not mark this release as latest. The most recent CLI release must be marked as latest. | ||
| # Set as a draft to give us an opportunity to review the rollback release. | ||
| gh release create \ |
There was a problem hiding this comment.
Will this print a link to the new release? It might be nice to add a link to the job summary to make it easier to move forwards to the next step of reviewing and publishing the release.
| on: | ||
| # You can trigger this workflow via workflow dispatch to start a rollback. | ||
| # This will create a draft release that mirrors the release for `rollback-tag`. | ||
| workflow_dispatch: |
There was a problem hiding this comment.
I assume this is intended to be triggered on main?
| uses: ./.github/actions/prepare-mergeback-branch | ||
| with: | ||
| base: "main" | ||
| head: "" |
| # - rollback_version: the version that we are rolling back, typically the one that followed `target_version` | ||
| # - new_version: the new version that we are releasing `target_version` as, typically the one that follows `rollback_version` | ||
| # | ||
| # Example: python3 .github/workflows/script/rollback_changelog.py "1.2.3" "1.2.4" "1.2.5" |
There was a problem hiding this comment.
If it's an easy change to make (perhaps Copilot can do it) named arguments via something like argparse would make this easier to read
This PR adds a new workflow that can be manually triggered to create a rollback release. I.e. the workflow creates a new release which mirrors an older, previous release. Since we publish immutable releases, this is necessary to "revert" a broken release.
The process is:
main. (For testing on a PR only: we checkout the repository at the PR head instead.)rollback_changelog.pyscript. There is some duplication among the Python scripts that could be neater, but I didn't want to tackle big improvements there as part of this PR.prepare_changelog.pyscript.package.jsonchanges targetingmain. (For testing on a PR only: we skip creating the PR, but still push the branch.)Once the process has completed:
This is best reviewed commit-by-commit.
Risk assessment
For internal use only. Please select the risk level of this change:
Merge / deployment checklist