JS Library 7/7: Pre-Releases and Nightly Releases

Note: Check out the entire supplemental source code for this blog series.

Pre-releases

If we want to keep merging changes into our library, but we’d prefer not to do so many releases, we can setup pre-releases. These releases will be tagged as a pre-release and will only be available to consumers who specifically ask for them.

To setup pre-releases with semantic-release we can create a next branch.

git checkout -b next
git reset --hard origin/main
git push -u origin next

This branch should already be protected due to our wildcard branch protection we setup in the previous step.

Next, we’ll need to tell semantic-release about our new branch:

./.releaserc.js

...
  branches: [
    'main',
    '+([0-9]).x',
    { name:  'next', prerelease:  true }
  ],
...

And we will need to tell our Release workflow to run on pushes to our new next branch:

./.github/workflows/release.yml

...
  on:
    push:
      branches:
        - 'main'
        - '[0-9]+.x'
        - 'next'
...

Now, whenever we merge a pull request into next, semantic-release will automatically do a pre-release.

Nightly Releases

For some teams, doing a pre-release every time you merge code might be too many releases. If we prefer, we could set up nightly releases to release from the next branch at the end of every day.

To setup nightly releases we will need to modify our Release workflow so that releases from next are triggered by a scheduled cron job instead of by a push to the branch:

./.github/workflows/release.yml

...
  on:
    push:
      branches:
        - 'main'
        - '[0-9]+.x'
    schedule:
      - cron: '0 6 * * *'  # run at 6am UTC
...

Note: that github actions will not guarantee that your cron job is triggered exactly when specified, it could be delayed by several minutes or even longer. Also, cron jobs default to checking out the last commit from the default branch, so in order for this to work properly we will need to change our default branch from main to next.

Merging next into main

To perform a regular release, simply merge next into main. To do this you should open a pull request to merge main into next. However, there is one paint point around this workflow. GitHub’s “Rebase and merge” merge button rewrites git history by creating new commits. This is usually not a problem on other branches, but for this reason I recommend not using the “Rebase and merge” button on GitHub to merge into the main branch. We can still keep the branch protected and require a pull request, but instead of hitting the button in the UI we can rebase next into main while preserving git history with the following commands:

git checkout main
git reset --hard origin/next
git push

Doing this will preserve git history and make future rebases much easier. Sometimes it might be useful to create a new branch protection rule specifically for main so that this important step isn’t forgotten.