github
@@ -46,13 +46,19 @@ jobs:
         CODEQL_VERSION_LATEST="$("$CODEQL_LATEST" version --format terse)"
         echo "Default CodeQL bundle version is $CODEQL_VERSION_DEFAULT"
         echo "Latest CodeQL bundle version is $CODEQL_VERSION_LATEST"
-        if [[ "$CODEQL_VERSION_DEFAULT" == "$CODEQL_VERSION_LATEST" ]]; then
-          # Just use `tools: null` to avoid duplication in the analysis job.
+
+        # If we're running on a pull request, run with both bundles, even if `tools: latest` would
+        # be the same as `tools: null`. This allows us to make the job for each of the bundles a
+        # required status check.
+        #
+        # If we're running on push, then we can skip running with `tools: latest` when it would be
+        # the same as running with `tools: null`.
+        if [[ "$GITHUB_EVENT_NAME" != "pull_request" && "$CODEQL_VERSION_DEFAULT" == "$CODEQL_VERSION_LATEST" ]]; then
           VERSIONS_JSON='[null]'
         else
-          # Use both `tools: null` and `tools: latest` in the analysis job.
           VERSIONS_JSON='[null, "latest"]'
         fi
+
         # Output a JSON-encoded list with the distinct versions to test against.
         echo "Suggested matrix config for analysis job: $VERSIONS_JSON"
         echo "::set-output name=versions::${VERSIONS_JSON}"

@@ -357,7 +357,7 @@ jobs:
         #
         # If we're running on push, then we can skip running with `tools: latest` when it would be
         # the same as running with `tools: null`.
-        if [[ "$GITHUB_EVENT_NAME" == "pull_request" && "$CODEQL_VERSION_DEFAULT" == "$CODEQL_VERSION_LATEST" ]]; then
+        if [[ "$GITHUB_EVENT_NAME" != "pull_request" && "$CODEQL_VERSION_DEFAULT" == "$CODEQL_VERSION_LATEST" ]]; then
           VERSIONS_JSON="[null, \"$NIGHTLY_URL\"]"
         else
           VERSIONS_JSON="[null, \"$NIGHTLY_URL\", \"latest\"]"

@@ -58,6 +58,20 @@ Here are a few things you can do that will increase the likelihood of your pull
 - Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
 - Write a [good commit message](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
 
+## 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.
+
+    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.
+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.
+
+    Approve the mergeback PR and automerge it. Once the mergeback has been merged into main, the release is complete.
+
 ## Resources
 
 - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)