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.

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 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 bash commands.

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.