Releasing new components with GitHub Actions
Let's automate the release of new components.
Automation is our friend...if we know what it does! In this lesson, we'll take a moment to understand at a high level what the GitHub Actions scripts do. We'll also see how we can release our component library to NPM through GitHub.
An added benefit of this is that we can remove any NPM publishing credentials from individuals and only have them in CI, thus minimizing the risk of leaking sensitive keys and credentials.
Understanding our CI scripts#
You may have noticed that the component library has two CI scripts:
Our main script both builds code and sends an updated state to Chromatic, while the release script is exactly the same but also publishes to NPM if we pass the Chromatic step.
Let's just take a high-level gander at our script.
In short, we can see how the YAML definition declares a
name, which we can also see in the GitHub user interface.
on bit defines when this script should trigger, which can be for single or multiple matches. You'll notice that the top
on.push.tags of the release script is different from
on.push.branches in the main one. This is because the main script runs on pushes to a branch (
main to be exact) while releasing works based on a tag instead. In our case, the tag has to start with a
v and can be followed by anything else. Practically speaking, to release, you would first push code to
main, ensure that it passes, and then create and push a tag for the current (working) commit. We will do this shortly.
jobs section is the big one—
release-components is just our own name, which in this case is purely semantic, matching the readable name at the top.
runs-on specifies what kind of system should be used for our script; in our case, it's a Linux machine with the Ubuntu operating system.
steps section declares the individual actions we want to do. This script is pretty straightforward and linear top-to-bottom. The steps use
names so that they can be listed and identified.
uses is a kind of shorthand for pointing to a pre-made Action.
run is just regular Linux
There are many ways we could slice and divide these and decide what each script should do.
First of all, we want a continuous, fast pipeline that verifies basic conformity (just being built is the lowest barrier I can think of). Since we want new changes to be built as feature branches, we can leave any hard restrictions away from those.
To support a controlled integration procedure, we add the extra step of verifying incoming changes in Chromatic when we get pull requests on the
Creating a tagged release#
Begin by navigating to your component library codebase.
Ensure that you are on the
main branch (run
git checkout main), that your code is fresh (with
git pull), that your code works, and that you are satisfied overall with what you've got.