Skip to content

Instantly share code, notes, and snippets.

@akhdaniel
Last active May 20, 2022 03:29
Show Gist options
  • Save akhdaniel/6b3aaf78109f762bbc8b5942a156fd30 to your computer and use it in GitHub Desktop.
Save akhdaniel/6b3aaf78109f762bbc8b5942a156fd30 to your computer and use it in GitHub Desktop.
Github CI/CD Setup

Overview

How to create a pipeline which checks your app's code quality -frequently, automatically, in the cloud - using GitHub Actions. Such as to lint, test and build your app hosted on GitHub.

Objectives

  • How to make a basic deploy pipeline for your code can setup quick, easily and for free.
  • It can run in the cloud whenever someone pushes to your repo. It will warn you when something fails. So in case you forgot to run tests locally or you edited in GitHub UI, you're covered.
  • GitHub supports a pipeline service called GitHub Actions, covered in this post.
  • We'll create sample workflow in this post to run a Hello World flow to print a message with a shell command.
  • Then we create a flow for a Node.js app - use this template to get you started.

Github Actions

  • GH Actions lets us run shell commands against our repo code using GH's cloud infrastructure and is triggered on an event, like a commit, a PR or on a schedule.

  • You can find an "Action" available in the Actions "marketplace" - it is like a plugin so you can do more complex tasks in your workflow without writing the code yourself. But that is not the focus of this post.

  • See the Actions page on GitHub[https://github.com/features/actions]

Deploy Pipeline CI/CD (Continuous Integration / Continuous Deployment)

  • The "Integration" part of the name is about testing your code. Typically you'd take commands you run locally and run them in a remote service. You are testing how your commits integrate with the existing codebase, perhaps running checks against a Pull Request and blocking a merge until the tests pass.

  • The "Deployment" part is about deploying code frequently

  • The "Continuous" part is automation to run the pipeline on every push and Pull Request. You don't have to remember to run the checks locally, as that can be tedious or forgotten. You just push local commits, or change a file on GitHub and the flow will run. For deploys, you don't need to connect to the remote server using SSH or FTP - you just commit and push and you site will deploy! The pipeline reduces effort and ensures you test the quality and deploy your code frequently.

Create a new pipeline

1 Create a new GitHub repo

Create a new GitHub repo. Or choose an existing one. It doesn't matter what code is in the repo - the first section here won't actually use the code. But if you have a Node.js repo, pick that, as it will be useful later.

2 Create a workflow

Click the "Actions" tab on your repo. Select: Skip this and set up a workflow yourself

Paste these codes

name: CI

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Run a one-line script
        run: echo "Hello, world!"

The key parts to note are the triggers (on a push event) and the steps (commands to run within a labeled "job"). You can name the job anything (no spaces). You only need one job in most cases.

You can have as many steps as you want. In the last step, the optional name field is just for logging purposed but run is the command that that gets run in the shell. We're using Ubuntu here as that is the typical choice for Actions.

Now save your file - click "Start commit" in the top right of GH or commit and push locally.

3 View Logs

You've added a new commit with that file, so your workflow's "push" condition will be triggered and it will run against the current code immediately.

View the Actions tab and find the logs for a run for this workflow - in this case only one run.

The workflow should log that it is successfully checked out your repo and then ran one step to print a greeting. Then it will finish with a green checkmark.

4 Make it fail

Edit your workflow file. Add 2 more steps.

To simulate a failed installation, lint error or failed unit test, the next step will exit with a non-zero code which means an error status. Instead of exit 1 you could also try using bad syntax or operating on a file that doesn't exit, for example mv foo bar.

steps:
      - uses: actions/checkout@v2

      - name: Greeting
        run: echo "Hello, world!"

      - name: Simulate an error
        run: echo "About to fail" ; exit 1

      - name: Another greeting
        run: echo "Hello, world!"

The last step won't be reached because the build will be aborted.

Save the file. Now when you view the latest build, you'll see an error message.

You should also get an email saying that your build failed. You'll also get a notification under the notifications section of your GH profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment