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

[haworku]

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 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:

2. 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.

[haworku]

🏆 @brandonlenz makes sense to me! Also good example of "Improve via marginal gains"

[brandonlenz]

@haworku I tried it out with 1.14.0:

git fetch --tags
git checkout 1.14.0
npm publish

I'll make a PR to the release process docs for the deliverable for this issue

[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 😆

[haworku]

@brandonlenz Eh, I'd vote to leave the current release process alone in that regard. Creating the tag on github does the release notes too in one step. I'd worry about someone messing something up in their command line who is new to the release process.

I really think we ultimately need to move towards something that automates tags. This issue captures some options for automated tagging: #326

This issue about locking main (or what you just tried out) are both stop gap measures until we do something better.

[haworku]

Closing this ticket, no longer needed because our release process has changed and we point release tags now at a specific commit hash not the main branch.