Intuit/Auto for Automating Release Workflow — Part 1
Managing releases has never been this easy!
Release management might seems trivial at first, but it is certainly one of the things we’d wish we started from the beginning of our project, or at least i did 😱.
Managing releases should at least consists of these activities:
- Versioning, much preferable to be in compliance with Semantic Versioning.
- Managing change log
- Managing releases: canary, pre-release, and latest build.
Why intuit/auto?
While there are a couple of tools we can use to automate above activities, intuit/auto
is powered by pull requests, something we’d surely expect to be used in a project involving team of developers or contributors 😀. So the overhead of implementing this automation is expected to be minimum.
Setting Up intuit/auto
For the sake of simplicity, we will be implementing intuit/auto
in a Javascript project on Github. It can be our existing project, or we can just simply create a new one.
First, install auto
in our project as devDependencies
. We surely can use npx auto
to run all of its command without having to install it locally. I pretty much prefer installing it locally since it helps in reducing my CI runner run time, since the intuit/auto
package should’ve existed in the cached node_modules
for subsequent runs. More on this later.
Then, add auto
into the script block in `package.json`.
Verify above script by running yarn auto -- -V
. It should outputs our newly installed package version.
Init auto
by running yarn auto -- init
. It would then prompt us to choose which package manager we are using. Let’s choose Git Tag
for this, since we won’t be publishing our project to the NPM repository.
It would then show what plugins we’d like to use. While we can install this later, i choose to use the Released
plugin. This plugin would automatically label the merged and released pull requests with released
.
Enter our Github repository address.
Enter our Github username and email we’d like to use for this project. This is what we usually do using git config user.name
and git config user.email
in each of our project.
Now, we have to choose whether to make a release only if the corresponding pull requests have a release
label. I choose not to use this, assuming that each pull request is a single buildable change, so each should have its release. Aside from that, we can use the skip-release
label to not make a release for specific pull request. More on this later.
Now, if we already have an .env
file at the root of our project, which is the same directory with where package.json
resides, we can skip below step.
As for the labels, we can skip this one for now.
The CLI should’ve stopped prompting us at this point. But wait, there’s more. While we have chosen to use Git Tag for our package manager, intuit/auto
CLI doesn’t actually install this plugin for us. So, before further steps, let’s install the needed package for this.
Voila! That’s an easy one!. intuit/auto
is now setup and configured in our project. We can visit our project folder and check for .autorc
.
Remember the create labels
prompt?. intuit/auto
has a predefined set of labels under the hood, consisting of major
, minor
, patch
, prerelease
, and many others. If we are certain to use these labels for our pull requests, we can run yarn auto -- create-labels
.
Warning: this would create and/or mutated the labels on our Github repository.
We can then visit our repository to see our newly created labels.
Next…
Now, that intuit/auto
is setup and configured in our project, this is the time for us to make some pull requests! 😀
We’ll be looking into how our pull requests play a part on this automated release workflow in the next part of this series. Stay tuned! 🤓