4

I'm searching for a tool/script that'd automate things I always need to do when publishing a new version of my open source library. Like:

  • npm version [major/minor/patch]
  • git push --tags
  • npm publish
  • create a new release on github
  • create a new pull request from develop into master branch
  • merge into master branch
  • maybe run built scripts and commit the built/dist-files
  • update versions in README.md
  • ect (not in that order obviously)

Is there a popular solution that other OSS maintainers are using or is everyone writing their own scripts?

If writing my own script is the best solution, who would I approach that (language etc)?

0

Both Jenkins & Travis continuous integration clients allow you a workflow that runs along the lines of:

  1. You commit to VCS
  2. Some specified interval later the CI tool checks the VCS and spots the new version.
  3. New build is attempted - if it succeeds
  4. Tests are run - if they pass
  5. New Release is deployed/uploaded to wherever.

You can even have branches/tags that get built and tested and others that get built, tested & deployed.

Both can build & test for multiple targets.

Both are free, gratis & open source and well used in the open source community.

There are a large number of CI tools that can do the same sort of thing, some are free, others not & some support only a limited subset of platforms but I believe the above are two of the most widely used in the open source community.

In terms of modifying your version information many VCS systems allow access to this either by variable substitution or scripting using hooks - these are most often either batch scripts (bash or bat) or python.

| improve this answer | |
0

I found the tool!

semantic-release

fully automated package publishing

Trust us, this will change your workflow for the better.

– egghead.io

Semantic Release is a tool designed to take Git commits, run tests, and publish your code all while following good SemVer spec for your version numbers.

When semantic-release got [sic] setup it will [generate changelogs and bump version] after every successful continuous integration build of your master branch (or any other branch you specify) and publish the new version for you. That way no human is directly involved in the release process and your releases are guaranteed to be unromantic and unsentimental.

As well as npm publishing, by default it supports pushing builds to GitHub as well.

This is what happens in series:

  1. git push New code is pushed and triggers a CI build.
  2. semantic-release pre Based on all commits that happened since the last release, the new version number gets written to the package.json.
  3. npm publish The new version gets published to npm.
  4. semantic-release post A changelog gets generated and a release (including a git tag) on GitHub gets created.

Note: The current release/tag implementation is tied to GitHub, but could be opened up to Bitbucket, GitLab, et al. Feel free to send PRs for these services.

(Formatting adapted.)

It also supports custom plugins, so you can write or find plugins to make it do whatever you want.

This is typically run on the CI server, rather than locally. And as a final note:

Is it really a good idea to release on every push?

It is indeed a great idea because it forces you to follow best practices. If you don’t feel comfortable making every passing feature or fix on your master branch addressable via npm you might not treat your master right. Have a look at branch workflows. If you still think you should have control over the exact point in time of your release, e.g. because you are following a release schedule, you can release only on the production/deploy/release branch and push your code there in certain intervals, or better yet use dist-tags.

| improve this answer | |
0

Because build/release pipelines are very specific to the specific technologies you're using, writing your own script is probably the best option. It gives you full control over what occurs in your pipeline.

All major scripting languages provide a way to hoist a command onto the command line. Thus, you just need to:

  1. Identify the exact steps required to build, test, & publish your library
  2. Determine what needs to change depending on the version of the new build
  3. Configure the script to follow these steps which you determined in (1) and (2).

I would suggest passing in the new version number. Additionally, make sure to test this script against a dummy upstream to avoid polluting your main project.

Many continuous integration tools can run tests on your code on every commit. I'd suggest using one of those to test and then your build script only has to bump version, build, and publish.

EDIT: I've pleasantly surprised myself by finding the tool designed to automate npm releases. As such, see my other answer. This answer remains as a general case, for cases in which the build pipeline is more complicated than semantic-release deals with. I still believe a custom build/release script is the best general-case solution.

| improve this answer | |
0

there is now an open source tool by zeitHQ which is as close as it gets: https://github.com/zeit/release

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.