Merge branch 'main' into hmakholm/pr/2.9.0

This commit is contained in:
Henning Makholm 2022-04-26 02:33:49 +02:00 committed by GitHub
commit 80771fd2d0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
30 changed files with 115 additions and 104 deletions

View file

@ -19,6 +19,9 @@ V1_MODE = 'v1-release'
# Value of the mode flag for a v2 release
V2_MODE = 'v2-release'
SOURCE_BRANCH_FOR_MODE = { V1_MODE: 'releases/v2', V2_MODE: 'main' }
TARGET_BRANCH_FOR_MODE = { V1_MODE: 'releases/v1', V2_MODE: 'releases/v2' }
# Name of the remote
ORIGIN = 'origin'
@ -191,8 +194,10 @@ def main():
type=str,
required=True,
choices=[V2_MODE, V1_MODE],
help=f"Which release to perform. '{V2_MODE}' uses main as the source branch and v2 as the target branch. " +
f"'{V1_MODE}' uses v2 as the source branch and v1 as the target branch."
help=f"Which release to perform. '{V2_MODE}' uses {SOURCE_BRANCH_FOR_MODE[V2_MODE]} as the source " +
f"branch and {TARGET_BRANCH_FOR_MODE[V2_MODE]} as the target branch. " +
f"'{V1_MODE}' uses {SOURCE_BRANCH_FOR_MODE[V1_MODE]} as the source branch and " +
f"{TARGET_BRANCH_FOR_MODE[V1_MODE]} as the target branch."
)
parser.add_argument(
'--conductor',
@ -203,14 +208,8 @@ def main():
args = parser.parse_args()
if args.mode == V2_MODE:
source_branch = 'main'
target_branch = 'v2'
elif args.mode == V1_MODE:
source_branch = 'v2'
target_branch = 'v1'
else:
raise ValueError(f"Unexpected value for release mode: '{args.mode}'")
source_branch = SOURCE_BRANCH_FOR_MODE[args.mode]
target_branch = TARGET_BRANCH_FOR_MODE[args.mode]
repo = Github(args.github_token).get_repo(args.repository_nwo)
version = get_current_version()
@ -247,9 +246,9 @@ def main():
print('Creating branch ' + new_branch_name)
if args.mode == V1_MODE:
# If we're performing a backport, start from the v1 branch
print(f'Creating {new_branch_name} from the {ORIGIN}/v1 branch')
run_git('checkout', '-b', new_branch_name, f'{ORIGIN}/v1')
# If we're performing a backport, start from the target branch
print(f'Creating {new_branch_name} from the {ORIGIN}/{target_branch} branch')
run_git('checkout', '-b', new_branch_name, f'{ORIGIN}/{target_branch}')
# Revert the commit that we made as part of the last release that updated the version number and
# changelog to refer to 1.x.x variants. This avoids merge conflicts in the changelog and

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

4
.github/workflows/__test-proxy.yml generated vendored
View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

4
.github/workflows/__test-ruby.yml generated vendored
View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -11,8 +11,8 @@ on:
push:
branches:
- main
- v1
- v2
- releases/v1
- releases/v2
pull_request:
types:
- opened

View file

@ -2,9 +2,9 @@ name: "CodeQL action"
on:
push:
branches: [main, v1, v2]
branches: [main, releases/v1, releases/v2]
pull_request:
branches: [main, v1, v2]
branches: [main, releases/v1, releases/v2]
# Run checks on reopened draft PRs to support triggering PR checks on draft PRs that were opened
# by other workflows.
types: [opened, synchronize, reopened, ready_for_review]

View file

@ -1,7 +1,8 @@
# This workflow runs after a release of the action.
# It merges any changes from the release back into the
# main branch. Typically, this is just a single commit
# that updates the changelog.
# This workflow runs after a release of the action. For v2 releases, it merges any changes from the
# release back into the main branch. Typically, this is just a single commit that updates the
# changelog. For v2 and v1 releases, it then (a) tags the merge commit on the release branch that
# represents the new release with an `vx.y.z` tag and (b) updates the `vx` tag to refer to this
# commit.
name: Tag release and merge back
on:
@ -14,8 +15,8 @@ on:
push:
branches:
- v1
- v2
- releases/v1
- releases/v2
jobs:
merge-back:
@ -32,7 +33,7 @@ jobs:
- name: Dump GitHub context
env:
GITHUB_CONTEXT: '${{ toJson(github) }}'
run: echo "$GITHUB_CONTEXT"
run: echo "${GITHUB_CONTEXT}"
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
@ -46,25 +47,25 @@ jobs:
id: getVersion
run: |
VERSION="v$(jq '.version' -r 'package.json')"
SHORT_SHA="${GITHUB_SHA:0:8}"
echo "::set-output name=version::$VERSION"
NEW_BRANCH="mergeback/${VERSION}-to-${BASE_BRANCH}-${SHORT_SHA}"
echo "::set-output name=newBranch::$NEW_BRANCH"
echo "::set-output name=version::${VERSION}"
short_sha="${GITHUB_SHA:0:8}"
NEW_BRANCH="mergeback/${VERSION}-to-${BASE_BRANCH}-${short_sha}"
echo "::set-output name=newBranch::${NEW_BRANCH}"
- name: Dump branches
env:
NEW_BRANCH: "${{ steps.getVersion.outputs.newBranch }}"
run: |
echo "BASE_BRANCH $BASE_BRANCH"
echo "HEAD_BRANCH $HEAD_BRANCH"
echo "NEW_BRANCH $NEW_BRANCH"
echo "BASE_BRANCH ${BASE_BRANCH}"
echo "HEAD_BRANCH ${HEAD_BRANCH}"
echo "NEW_BRANCH ${NEW_BRANCH}"
- name: Create mergeback branch
env:
NEW_BRANCH: "${{ steps.getVersion.outputs.newBranch }}"
run: |
git checkout -b "$NEW_BRANCH"
git checkout -b "${NEW_BRANCH}"
- name: Check for tag
id: check
@ -72,13 +73,13 @@ jobs:
VERSION: "${{ steps.getVersion.outputs.version }}"
run: |
set +e # don't fail on an errored command
git ls-remote --tags origin | grep "$VERSION"
EXISTS="$?"
if [ "$EXISTS" -eq 0 ]; then
echo "Tag $TAG exists. Not going to re-release."
git ls-remote --tags origin | grep "${VERSION}"
exists="$?"
if [ "${exists}" -eq 0 ]; then
echo "Tag ${VERSION} exists. Not going to re-release."
echo "::set-output name=exists::true"
else
echo "Tag $TAG does not exist yet."
echo "Tag ${VERSION} does not exist yet."
fi
# we didn't tag the release during the update-release-branch workflow because the
@ -89,20 +90,31 @@ jobs:
env:
VERSION: ${{ steps.getVersion.outputs.version }}
run: |
git tag -a "$VERSION" -m "$VERSION"
git fetch --unshallow # unshallow the repo in order to allow pushes
git push origin --follow-tags "$VERSION"
# Unshallow the repo in order to allow pushes
git fetch --unshallow
# Create the `vx.y.z` tag
git tag --annotate "${VERSION}" --message "${VERSION}"
# Update the `vx` tag
major_version_tag=$(cut -d '.' -f1 <<< "${VERSION}")
# Use `--force` to overwrite the major version tag
git tag --annotate "${major_version_tag}" --message "${major_version_tag}" --force
# Push the tags, using:
# - `--atomic` to make sure we either update both tags or neither (an intermediate state,
# e.g. where we update the v2.x.y tag on the remote but not the v2 tag, could result in
# unwanted Dependabot updates, e.g. from v2 to v2.x.y)
# - `--force` since we're overwriting the `vx` tag
git push origin --atomic --force refs/tags/"${VERSION}" refs/tags/"${major_version_tag}"
- name: Create mergeback branch
if: steps.check.outputs.exists != 'true' && contains(github.ref, 'v2')
if: steps.check.outputs.exists != 'true' && contains(github.ref, 'releases/v2')
env:
VERSION: "${{ steps.getVersion.outputs.version }}"
NEW_BRANCH: "${{ steps.getVersion.outputs.newBranch }}"
GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
run: |
set -exu
PR_TITLE="Mergeback $VERSION $HEAD_BRANCH into $BASE_BRANCH"
PR_BODY="Updates version and changelog."
pr_title="Mergeback ${VERSION} ${HEAD_BRANCH} into ${BASE_BRANCH}"
pr_body="Updates version and changelog."
# Update the version number ready for the next release
npm version patch --no-git-tag-version
@ -110,16 +122,16 @@ jobs:
# Update the changelog
perl -i -pe 's/^/## \[UNRELEASED\]\n\nNo user facing changes.\n\n/ if($.==3)' CHANGELOG.md
git add .
git commit -m "Update changelog and version after $VERSION"
git commit -m "Update changelog and version after ${VERSION}"
git push origin "$NEW_BRANCH"
git push origin "${NEW_BRANCH}"
# PR checks won't be triggered on PRs created by Actions. Therefore mark the PR as draft
# so that a maintainer can take the PR out of draft, thereby triggering the PR checks.
gh pr create \
--head "$NEW_BRANCH" \
--base "$BASE_BRANCH" \
--title "$PR_TITLE" \
--head "${NEW_BRANCH}" \
--base "${BASE_BRANCH}" \
--title "${pr_title}" \
--label "Update dependencies" \
--body "$PR_BODY" \
--body "${pr_body}" \
--draft

View file

@ -2,7 +2,7 @@ name: PR Checks (Basic Checks and Runner)
on:
push:
branches: [main, v1, v2]
branches: [main, releases/v1, releases/v2]
pull_request:
# Run checks on reopened draft PRs to support triggering PR checks on draft PRs that were opened
# by other workflows.

View file

@ -2,7 +2,7 @@ name: Test Python Package Installation on Linux and Mac
on:
push:
branches: [main, v1, v2]
branches: [main, releases/v1, releases/v2]
pull_request:
# Run checks on reopened draft PRs to support triggering PR checks on draft PRs that were opened
# by other workflows.

View file

@ -7,7 +7,7 @@ on:
# When the v2 release is complete, this workflow will open a PR to update the v1 release branch.
push:
branches:
- v2
- releases/v2
jobs:
update:

View file

@ -61,22 +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 `v2` 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 `releases/v2` release branch.
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. The workflow run will open a pull request titled "Merge main into releases/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 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.
1. When the "Merge main into releases/v2" pull request is merged into the `releases/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 releases/v2" pull request, and bumps the patch version of the CodeQL Action.
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.
1. When the "Merge main into releases/v2" pull request is merged into the `releases/v2` branch, the "Update release branch" workflow will create a "Merge releases/v2 into releases/v1" pull request to merge the changes since the last release into the `releases/v1` release branch.
This ensures we keep both the `releases/v1` and `releases/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.
1. Once the mergeback has been merged to `main` and the "Merge releases/v2 into releases/v1" PR has been merged to `releases/v1`, the release is complete.
## Keeping the PR checks up to date (admin access required)
@ -91,8 +91,8 @@ To regenerate the PR jobs for the action:
CHECKS="$(gh api repos/github/codeql-action/commits/${SHA}/check-runs --paginate | jq --slurp --compact-output --raw-output '[.[].check_runs | .[].name | select(contains("https://") or . == "CodeQL" or . == "LGTM.com" or . == "Update dependencies" or . == "Update Supported Enterprise Server Versions" | not)]')"
echo "{\"contexts\": ${CHECKS}}" > checks.json
gh api -X "PATCH" repos/github/codeql-action/branches/main/protection/required_status_checks --input checks.json
gh api -X "PATCH" repos/github/codeql-action/branches/v2/protection/required_status_checks --input checks.json
gh api -X "PATCH" repos/github/codeql-action/branches/v1/protection/required_status_checks --input checks.json
gh api -X "PATCH" repos/github/codeql-action/branches/releases/v2/protection/required_status_checks --input checks.json
gh api -X "PATCH" repos/github/codeql-action/branches/releases/v1/protection/required_status_checks --input checks.json
````
2. Go to the [branch protection rules settings page](https://github.com/github/codeql-action/settings/branches) and validate that the rules have been updated.

View file

@ -108,7 +108,7 @@ for file in os.listdir('checks'):
},
'on': {
'push': {
'branches': ['main', 'v1', 'v2']
'branches': ['main', 'releases/v1', 'releases/v2']
},
'pull_request': {
'types': ["opened", "synchronize", "reopened", "ready_for_review"]