How to do a release when PRs are required?

[jbcpollak]

We have a project with Require a pull request before merging enabled on main.

I would like to setup a process where a set of PRs are merged to main, then at some point we decide to make a release and either manually, or (ideally) automatically, we trigger a GitHub Action to run release publish.

How do we get past the "require pr" block? If I run it locally, I don't want to make a PR for the release, and I don't think you can make empty PRs.

[kettanaito]

Hey, @jbcpollak.

If I understand the issue correctly, required PRs imply that the release commit that this tool creates won't get accepted in GitHub because of that requirement (GH will fail saying "need to create a pull request"). If that's the case, then you typically circumvent this by:

1. Configuring the repo to exclude administrators from this rule.
2. Generate a personal access token as an administrator.
3. Set it on the CI as described in this recipe.

I don't remember but the first step may not even be needed. You may test that and let me know.

Releasing from local would follow the same procedure. You need to keep that personal access token in an .env file (or elsewhere) and provide it to the release publish command because it requires that env variable anyway.

[kettanaito]

If you don't wish to breach the rule, you may consider creating a maintenance user for your repository/organization, making it an admin, and whitelisting only that user. Respectively, you'd have to use its token in the CI for the release commits to be pushed.

[jbcpollak]

makes sense, I'll give that a go. I think our /mergeit tool I mentioned else where may already be doing something similar. I don't want this to happen as part of that tool, but I can probably reuse the logic.

[jbcpollak]

Hi @kettanaito - so I tried this with a maintenance user and a new personal access token. The problem is that we also have the follow rule enabled, which as far as I can tell can't be worked around. To make release work, we'd have to branch and make a PR, wait for the builds to pass, then automerge.

We could insert release into our regular PR process, but we want releases to be roll-ups of a series of merged PRs, not just a single one.

[jbcpollak]

Ok, here is the solution I've come up with, which I'm not happy about but works for now. The rough process is to work with the branch protection rules instead of around them, using this action. Note this gets around branch protection rules but not pull request rules, so the personal access token you use for this process must be a user with admin privileges that can either temporarily remove the PR requirement or is a user allowed to bypass the requirement.

Disable release's push

in publish.ts, comment out this line: await this.pushToRemote()

This means release won't do the push. I don't like it, but we'll work around it later.

Update your package.json to use this modified version of release. You can for example use:

  "devDependencies": {
    "@ossjs/release": "jbcpollak/release#907eca4b1e109ac9c7d31f0d53900f93897fb15e"
  }

Use the following Github Action config

      # Do the semrel work
      - name: Perform Release
        run: |
          ./node_modules/.bin/release publish
        env:
          GITHUB_TOKEN: ${{ secrets.RELEASE_TOKEN }}

      # Get the calculated release version for rollback later, if necessary
      - name: get-npm-version
        id: package-version
        uses: martinbeentjes/npm-get-version-action@main

      # Push to main via a branch and waiting for branch protection status checks to pass
      - name: Merge version update to main
        id: merge-to-main
        uses: CasperWA/push-protected@v2.12.0
        with:
          token: ${{ secrets.RELEASE_TOKEN }}
          branch: main
          timeout: 30
          sleep: 30
          unprotect_reviews: true

      # Remove the tag if the merge to main failed any checks, using the calculated release version
      - name: action-slack
        if: failure() && steps.merge-to-main.outcome != 'success'
        run: |
          echo "Deleting the release tag"
          git push --no-verify --delete origin ${{ steps.package-version.outputs.current-version}}

What this does is:

• use release to calculate the new version number and prep package.json, make and push a tag and generate the GitHub release.
• cache the new version number
• uses push-protected to push to a branch, wait for the branch protection rules to pass, then merge to main.
• if the above merge fails, roll back the changes.

Analysis

Obviously, this duplicates a lot of the work release is intended to do, and worse, is out of order because the release is made of GitHub before the changes are merged to main. Most of the rollback protections built into release are circumvented and have to be duplicated in the Action itself.

I don't see a good resolution to this mess here:

One option is to extend release to support the push-to-branch and wait for status check behavior, but that's highly specific to our use-case, and to GitHub Actions also.

The other option is to reproduce release's functionality as a GitHub Action, doing each of the steps at the workflow (or action yml) level. This is obviously GitHub specific, but because GitHub doesn't offer any other options for bypassing checks, I don't see any other options.

[kettanaito]

It's a common problem of "Require status check" to trigger on a release push. I believe tools like Semantic Release provide some documentation around this. Afaik, using an admin PAT should bypass this rule but I personally had trouble making it behave so.