Setting up CI (Continuous Integration) to your project used to be a good bit of work. If you stored your code in Github, you would need to setup an account with Jenkins, CircleCI or others, and go through the arduous process of getting the two systems to talk to one another, in short, it was a bit of a pain in the a**.
Github Actions came on the scene last year and what makes it so awesome is if you already have your code in Github, you can setup a pipeline in minutes, not hours. In this guide I'll show you how you can setup your own pipeline with Github actions in as little as 5 minutes!
Prerequsites
This guide assumes that you have the following already setup:
- A Javascript project in Github
- Package Scripts to run linting, typechecking, testing, etc.
With that out of the way lets get started
Setting up your workflow file.
Github actions runs off of a workflow file, this file will tell Github how to setup the CI machine and what to do after it's been setup. To get started, create a folder in the root of your directory called .github
. From there go inside that folder and create another folder called workflows
. Going inside that folder again, create a YAML file, it can be whatever name you want (I usually do something boring like ci.yaml
)
Once you've created the workflow file, paste this inside:
name: CI
on:
pull_request:
types: [opened, closed]
branches: ['main']
jobs:
job-name:
runs-on: ubuntu-latest
strategy:
matrix:
node-versions: [12.x]
steps:
# Setup steps
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
# User defined steps
- run: sudo npm install -g yarn
- run: yarn
- run: yarn lint
- run: yarn test
env:
CI: true
So let's break down what's going on in this file. First off at the top you have the name which you want to call the workflow. Again it can be anything you want.
Below that you have the on:
block, this block defines when the workflow is run on and on which branches. This workflow is meant to run on a pull request and runs whenever one is opened or closed, it's also restricting runs to PR's that are opened against the main
branch. If you have other branches like develop
or release
, you can add them into that block as well.
Below the on:
block you have a strategy:
block. This defines which version of node you are using. In this case we are using a matrix and specifying that we want to run the jobs with a node version that is v12.x.x.
Finally at the bottom is the meat and potatoes of the workflow, the steps
block. The first few steps are there to setup NodeJS but below that you can define your own steps.
In this example, my project uses yarn
so the first step is to install that then to run the lint
and test
commands. You can add, remove and modify these steps according to what is in your package.json
Opening a PR.
Once you have finished setting up the worflow file, commit your changes to a branch and then open a PR into your main
branch. When you do that, the CI will automatically kick off and start running.
I hope this quick guide helps everyone in keeping their code more reliable. This is a pretty basic setup and will let you add functionality as you continue to grow your project.
Top comments (0)