From da7944b1654f45f347b4222e255c7955ccc80303 Mon Sep 17 00:00:00 2001 From: Henry Mercer Date: Thu, 24 Mar 2022 15:41:49 +0000 Subject: [PATCH] Update release process doc --- CONTRIBUTING.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 54f597b9b..5a1e6c1c0 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -61,16 +61,22 @@ Here are a few things you can do that will increase the likelihood of your pull ## Releasing (write access required) 1. The first step of releasing a new version of the `codeql-action` is running the "Update release branch" workflow. - This workflow goes through the pull requests that have been merged to `main` since the last release, creates a changelog, then opens a pull request to merge the changes since the last release into the `v1` release branch. + This workflow goes through the pull requests that have been merged to `main` since the last release, creates a changelog, then opens a pull request to merge the changes since the last release into the `v2` release branch. - A release is automatically started every Monday via a scheduled run of this workflow, however you can start a release manually by triggering a run via [workflow dispatch](https://github.com/github/codeql-action/actions/workflows/update-release-branch.yml). -1. The workflow run will open a pull request titled "Merge main into v1". Mark the pull request as [ready for review](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#marking-a-pull-request-as-ready-for-review) to trigger the PR checks. + You can start a release by triggering this workflow via [workflow dispatch](https://github.com/github/codeql-action/actions/workflows/update-release-branch.yml). +1. The workflow run will open a pull request titled "Merge main into v2". Mark the pull request as [ready for review](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request#marking-a-pull-request-as-ready-for-review) to trigger the PR checks. 1. Review the checklist items in the pull request description. - Once you've checked off all but the last of these, approve the PR and automerge it. -1. When the "Merge main into v1" pull request is merged into the `v1` branch, the "Tag release and merge back" workflow will create a mergeback PR. - This mergeback incorporates the changelog updates into `main`, tags the release using the merge commit of the "Merge main into v1" pull request, and bumps the patch version of the CodeQL Action. + Once you've checked off all but the last two of these, approve the PR and automerge it. +1. When the "Merge main into v2" pull request is merged into the `v2` branch, the "Tag release and merge back" workflow will create a mergeback PR. + This mergeback incorporates the changelog updates into `main`, tags the release using the merge commit of the "Merge main into v2" pull request, and bumps the patch version of the CodeQL Action. - Approve the mergeback PR and automerge it. Once the mergeback has been merged into main, the release is complete. + Approve the mergeback PR and automerge it. +1. When the "Merge main into v2" pull request is merged into the `v2` branch, the "Update release branch" workflow will create a "Merge v2 into v1" pull request to merge the changes since the last release into the `v1` release branch. + This ensures we keep both the `v1` and `v2` release branches up to date and fully supported. + + Review the checklist items in the pull request description. + Once you've checked off all the items, approve the PR and automerge it. +1. Once the mergeback has been merged to `main` and the "Merge v2 into v1" PR has been merged to `v1`, the release is complete. ## Keeping the PR checks up to date (admin access required)