[feat] Lock main branch while a release is in progress.

Does your feature request relate to a specific USWDS feature? No this is related to dev flow and releasing

Is your feature request related to a problem? Please describe. We should ensure that merges to main branch don’t happen while a release is in progress. Our single branch release flow calculates the changelog based on already merged work at that time and also determines the release version. We don’t want random changes being introduced anytime between when a release PR opens and the release is tagged on github after that release PR merges.

Describe the solution you’d like

Let’s ensure our mainline branch is locked while a release is in process. Make a “Safe to Merge” GH action or danger check that fails when there is an open release PR to main. Open release PRs can be identified either by their title ( chore(release)) and/or by label (release).

Describe alternatives you’ve considered Using clear communication between devs can also be a way to avoid merging during releases. However dependabot could still merge while a release is in progress.

[brandonlenz]

@haworku actually this doesn’t quite do what I was hoping because of the way we squash commits and delete the release branch on merge. So the release commit is actually the commit on main, NOT the commit from standard-version on the release branch (which would not include updates to main from after the release started).

Sooo I’ll hold off on that PR to update the docs.

We could tag the release branch before merging back to main and deleting it per https://stackoverflow.com/questions/54281360/what-happens-to-tags-of-squashed-commits. We would have to make the process more like

1. Open the release PR
2. Once you have approval on the release PR, create the tag from the release branch
3. merge (squash and delete) the release branch

Anyways, I was hoping for an easy win here, but its slightly trickier that I originally thought, and I’m not sure how I feel about it anymore 😆

[brandonlenz]

@haworku I’m curious on a possible alternative here. Since it is possible for main to receive commits anytime after the yarn release and before npm publish, the following process changes are easy to implement and don’t involve worrying about code freezes or implementing automation. We could effectively solve this issue with just a couple of changes to our releasing docs:

1. Specify the “chore(release): […]” commit when creating the tag in Github under Step 5:

1. Checkout the tag instead of main before running npm publish

Then our bullets for step 5 would look something like this, which should solve these problems:

• Merge the PR and create a new release tag pointed at the release commit on Github. Use the same notes as release PR.
  • Pull down the release tag locally before publishing:
    • git fetch --tags
    • git checkout {TAG_VERSION}, e.g. git checkout 1.13.2
  • Publish the new package to npm: npm publish. You will be prompted for a MFA code.
    • You may need to npm login first.
    • Publishing access is limited to package owners. If you need access and don’t have it, please contact @npm-admins on Truss Slack.