Web developer, award-losing photographer and dog friend.
Making new releases is one of the most boring and tedious tasks in open source.
There are many tools that try to automate publishing and one of the most interesting is semantic-release. I was avoiding it for a long time because it makes publishing fully automated with changelogs generated from commit messages, and I believe that changelogs must be written by humans.
But actually it’s very flexible and I was able to customize it to do exactly what I want:
Below I’ll describe my own set of scripts that implements this workflow.
First install semantic-release command line tool:
npm install -g semantic-release-cli
Then run it in your project folder:
Enter your npm and GitHub credentials. Choose “Create no .travis.yml” if you already have one, otherwise it will be overwritten.
Add these lines to your travis.yml:
- npm run semantic-release
You can change semantic-release behavior with plugins: detect release type, check release requirements (like a changelog), generate changelog, etc. I made a package with all plugins I need to support my workflow.
First install the plugins:
npm install --save-dev semantic-release-tamia
Then add to your package.json:
Run npm install and npm run semantic-release to test if everything works. You’ll see something like that:
semantic-release WARN pre semantic-release didn’t run on Travis CI and therefore a new version won’t be published.
semantic-release WARN pre You can customize this behavior using "verifyConditions" plugins: git.io/sr-plugins
semantic-release ERR! pre Failed to determine new version.
semantic-release ERR! pre ENOCHANGE There are no relevant changes, so no new version is released.
Which is fine and means two things: semantic-release will not make a release until it runs in a CI environment and you have no changes that could be published.
Each commit message consists of:
Semantic-release uses this tags to find all important commits for the release (Fix is important, Docs is not) and determine which version (MAJOR, MINOR or PATCH) should be released.
I wrote a script to help me with changelogs.
First run sr-changelog. It will create a file with all important commits for the release grouped by type (breaking changes, new features and bugfixes) and open it in your default editor.
Now you can rewrite your changelog to make it useful and easy to read for your users.
Then run sr-changelog commit. It will make a commit without changes (git commit — allow-empty) of type Changelog and changelog in the commit message body.
Now you need to git push your changes and make some coffee.