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.
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
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.
auto into the script block in `package.json`.
Verify above script by running
yarn auto -- -V. It should outputs our newly installed package version.
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
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
create labels prompt?.
intuit/auto has a predefined set of labels under the hood, consisting of
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.
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! 🤓