easwee.net // tiny digital playground

devlog - github actions

I've been migrating a lot of Gitlab deployment pipelines to Github lately. Github actions are a nice thing, but take some getting used to, before you can mirror your deployment strategy to the one you had on Gitlab. Writing down some public personal notes for future reference:

• install a yaml validator plugin for your editor before you even start
• when searching for resources do not trust any blogs including this one; they are a good reference but syntax they provide is most likely outdated; always consult official Github Actions docs
• always check if there is a newer version of a public action
• Act is a nice tool, but it is not 1:1 compared to running actions on Github
• use reusable workflows, they take some time to set up, but once all input vars are set correctly it speeds up setting up multiple environments pipelines
• reusable workflows can't have a dynamic tag; you either have to specify a branch, version or commit hash (obvious security reasons), same goes for actions
• don't forget to cache dependencies and everything you can to speed up your pipelines; pipeline re-run times can be greatly reduced with caching and storing artifacts
• don't forget to expire your artifacts in a reasonable time (after some time Github will expire them for you)
• you can read Github token with ${{ secrets.GITHUB_TOKEN }}, but in a reusable workflow you have to read it with ${{ github.token }}
• reduce log output using --silent, --quiet or whatever flag silences your log output for desired command
• you can't run deploy feature branch reviews on Github Pages; this would be a nice feature, but they only allow 1 Github Pages deployment per repository, so you will need external hosting for review deployments
• use ${{ github.head_ref }} when you need your branch name
• consult docs for hosted runners to see which tools are preinstalled for you in hosted runners before you go complicating your workflows with custom installs; complete lists of what each runner contains are available, like this one for ubuntu runner: https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-Readme.md
• you can use workflow_dispatch to trigger workflows manually from Github; UI for this is kinda clunky at the moment, but it works (do note GH actions are in active development); you also have API if you want
• you can specify a deployment environment and protect the workflow to only allow pipeline runs triggered from branches allowed to deploy to specified environments. this will instantly exit the job if requirements to deploy to env are not met:

job_name:
  environment:
    name: production
    url: https://www.example.com

• you can share values between jobs with outputs; I needed to sanizite a branch name to reuse in deployment urls later. Example of using outputs between jobs:

jobs:
  sanitize_branch:
    name: sanitize branch name job
    runs-on: ubuntu-latest
    outputs:
      output: ${{ steps.sanitize_branch.outputs.sanitized_branch }}
    steps:
      - id: sanitize_branch
        run: |
          REPO="${{ github.head_ref }}"
          REPO_SANITIZED="${REPO////-}"
          echo "::set-output name=sanitized_branch::${REPO_SANITIZED}"
  another_job:
    needs: [sanitize_branch]
    name: just another separate job
    runs-on: ubuntu-latest
    steps:
    	- run: echo ${{needs.sanitize_branch.outputs.output}}

• use npm ci to run your npm actions (or equivalent for your package manager)
• macOS runners cost 10x more per minute than Linux runners; pick macOS only when you really need it, it is not a thing of preference

Github is not the same in terms of features compared to Gitlab, but with a few workarounds on Github and Github Actions you get to same or similar results.