automatic-release
Advanced tools
Automates the full release process for Open Source projects on GitHub, using Travis CI and deploying to NPM.
Automates the full release process for Open Source projects on GitHub, using Travis CI and deploying to NPM.
automatic release automates the whole release process for Open Source projects in GitHub by:
When used in combination with the Git Flow branching model and a Continuous Integration platform such as Travis CI, releasing a library to NPM & GitHub gets as easy as merging the latest development state into the master branch.
To get automatic-release via npm, simply add it as a new dev-dependency to your package.json file and run npm install. Alternatively, run the following command:
npm install automatic-release --save-dev
Requirements
Make sure to at least use NodeJS 7.6 (or higher). This is required due to automatic-release using the async-await functionality internally. Earlier 7-ish versions of NodeJS (versions ranging from 7.0 to 7.5) can also be used - however, running automatic-release together with the --harmony-async-await flag is necessary then.
automatic-release expects a package.json and a CHANGELOG.md file at the project root level. Furthermore, the package.json file should at least define a name, a version, and a repository URL.
Internally, automatic-release analyzes the commit history in order to evaluate the next version as well as generate the changelog. To make this work, developers have to follow a specific convention when making commits. Such a convention often consists of a commit message (including the commit type, scope, and change message), a commit body (with further details), and a commit footer (describing breaking changes or listing issues this commit fixes).
As of now, this project expects the Angular Commit Message Format to be used. Read the full Angular commit message guidelines right here. To give you a first impression, commits following this convention look similar to the following:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Tip: Not every commit has to follow this convention. Instead, it's probably better to squash commits of a Pull Request before merging, and then only name the PR merge commit after the naming convention.
Also, following the Git Flow branching model is highly recommended. In short, Git Flow proposes a number of branch types, such as the master branch (containing the latest release), the develop branch (as the "master during development"), and multiple feature & bugfix branches (to enable developers to work in a parallel manner). Utilizing this concept allows us to simplify the overall release process significantly (amongst further advantages for the overall development workflow).
However, you are not forces to use all the branches Git Flow proposes - automatic-release expects at least the follwing branches to be used in their correct way:
To get to know more about the Git Flow concept and what advantages it brings to the table, continue reading this article.
First of all, setup Travis CI for your GitHub repository. This includes:
.travis.yml configuration file set upFor further details on how to setup Travis CI, continue reading the official Getting Started guide.
Within Travis CI, add the following Environment Variables for your GitHub repository (in the Settings section):
GH_TOKEN: This environment variable defines the GitHub Access Token, needed by automatic-release to push commits & tags to GitHub as well as create releases. To generate such a token, visit your Personal Access Tokens page, and generate a new token with the repo scope being enabled.NPM_TOKEN: This environment variable contains the NPM Authentication Token, needed by Travis CI to deploy your library to the official public NPM registry. Getting this token is as simple as logging into your NPM account locally, and taking the authToken from your .npmrc file. More specific instructions can be found right here.Now, extend your .travis.yml configuration file with the following steps (replacing the <...> parts with real data):
master branch is included in the branches block, so that a push to (merge from develop into) master actually triggers a release. For example:
branches:
only:
- master # Used for publishing releases automatically
- develop
before_install block:
before_install:
- if [ "$TRAVIS_BRANCH" == "master" ]; then
git clone "https://github.com/$TRAVIS_REPO_SLUG.git" "$TRAVIS_REPO_SLUG";
cd "$TRAVIS_REPO_SLUG";
git checkout -qf "$TRAVIS_COMMIT";
fi
Solution inspired by this discussion on StackOverflow.
before_deploy block:
before_deploy:
- git config --global user.name "<GITHUB_USER_NAME>" # Replace!
- git config --global user.email "<GITHUB_USER_EMAIL>" # Replace!
- git config credential.helper "store --file=.git/credentials"
- echo "https://$GH_TOKEN:@github.com" > .git/credentials
- git checkout master
- npm run automatic-release # Here happens the magic
To make
npm run automatic-releasework, you have to add"automatic-release": "automatic-release"to thescriptsblock in yourpackage.jsonfile.
deploy block - in this case deploying directly to the public NPM registry:
deploy:
provider: npm
email: <NPM_USER_EMAIL> # Replace!
api_key: "$NPM_TOKEN"
skip_cleanup: true
on:
branch: master
repo: <GITHUB_REPO_USER>/<GITHUB_REPO_NAME> # Replace!
Besides this library, there are a lot of other tools out there related to automatic releases / deployments. The following are a few I can recommend, and which perfectly complement the automatic-release library.
after_deploy block of the .travis.yml file, in which case it looks more like it lists the successfully published files.Right now, this tool is rather basic; there are lots of features & enhancements that would be nice to have, such as:
You can't wait for one of those features, or have some new ideas?
Simply create an issue. Also, contributions to this project are highly welcomed at all time!
Dominique Müller
FAQs
Automates the full release process for Open Source projects on GitHub, using Travis CI and deploying to NPM.
The npm package automatic-release receives a total of 89 weekly downloads. As such, automatic-release popularity was classified as not popular.
We found that automatic-release demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
ENISA’s 2025 Threat Landscape report highlights how AI is reshaping cyber attacks, driving phishing, model poisoning, and software supply chain risks.
Security News
Evan You announces Vite+, a commercial, Rust-powered toolchain built on the Vite ecosystem to unify JavaScript development and fund open source.
Security News
Ruby Central’s incident report on the RubyGems.org access dispute sparks backlash from former maintainers and renewed debate over project governance.