Skip to content

Latest commit

 

History

History
88 lines (60 loc) · 2.75 KB

RELEASING.md

File metadata and controls

88 lines (60 loc) · 2.75 KB
Raw

Releasing

We've moved to GitHub Actions for releases.

How a release works

Releases trigger when the repository recieves the custom repository_dispatch event release-triggered.

This triggers the publish.yml workflow, which in turn triggers the release.sh script in scripts/ci. The workflow will also create a github release with an appropriate changelog.

Having the release triggered by a custom event is useful for automating releases in the future (eg for version bumps in pact dependencies).

Release.sh

This script is not intended to be run locally. Note that it modifies your git settings.

The script will:

  • Modify git authorship settings
  • Confirm that there would be changes in the changelog after release
  • Run Lint
  • Run Build
  • Run Test
  • Commit an appropriate version bump, changelog and tag
  • Package and publish to npm
  • Push the new commit and tag back to the main branch.

Should you need to modify the script locally, you will find it uses some dependencies in scripts/ci/lib.

Kicking off a release

You must be able to create a github access token with repo scope to the jest-pact repository.

  • Set an environment variable GITHUB_ACCESS_TOKEN_FOR_PF_RELEASES to this token.
  • Make sure master contains the code you want to release
  • Run scripts/trigger-release.sh

Then wait for github to do its magic. It will release the current head of master.

Note that the release script refuses to publish anything that wouldn't produce a changelog. Please make sure your commits follow the guidelines in CONTRIBUTING.md

If the release fails

The publish is the second to last step, so if the release fails, you don't need to do any rollbacks.

However, there is a potential for the push to fail after a publish if there are new commits to master since the release started. This is unlikely with the current commit frequency, but could still happen. Check the logs to determine if npm has a version that doesn't exist in the master branch.

If this has happened, you will need to manually put the release commit in.

# First delete the new tag
#   somehow this ends up in the repository
#   even though the push fails.

git checkout master
git pull --tags
git tag -d <broken-version>
git push -delete origin <broken-version>


# If there are changes that introduce features, then you'll have to branch and probably rebase

# Now create a new commit + tag for the version:
npm run release

# Push that tag + commit
git push origin master --follow-tags
  • Don't forget to create a new release in github.

Depending on the nature of the new commits to master after the release, you may need to rebase them on top of the tagged release commit and force push (only do this if the released version would be different to the version tagged by npm run release)