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: main.yml
and release.yml
.
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.
name: 'Release components'
on:
push:
tags:
- "v*"
jobs:
release-components:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Install dependencies
run: |
npm install --force
npm install react react-dom styled-components prop-types --save
- name: Build components
run: |
npx figmagic --token ${{ secrets.FIGMA_TOKEN }} --url ${{ secrets.FIGMA_URL }}
npm run build
- name: Publish to Chromatic
uses: chromaui/action@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
projectToken: ${{ secrets.CHROMATIC_TOKEN }}
- uses: actions/setup-node@v1
with:
node-version: 14
registry-url: https://registry.npmjs.org/
- run: git config --global user.email ${{ secrets.GIT_EMAIL }}
- run: git config --global user.name ${{ secrets.GIT_NAME }}
- run: npm publish --access public
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
Tiny primer#
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.
The 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.
The 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.
The steps
section declares the individual actions we want to do. This script is pretty straightforward and linear top-to-bottom. The steps use name
s 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 bash
commands.
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 main
branch.
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.
This page is a preview of The newline Guide to React Component Design Systems with Figmagic