GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository. For example, you can run a workflow to automatically add the appropriate labels whenever someone creates a new issue in your repository.

GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

Suggested Learning Path

• High-level overview of GitHub Actions
  • Key Concepts
    • Workflows - Automated process, such as build and deploy an application
    • Events - Casue workflows to execute. Event Types include:
      • Scheduled like CRON
      • Manually create by clicking a button
      • Triggered by an action ex. opening a pull request
    • Jobs - Set of steps comprising a logic unit of work in your process.
      • Can have more than one in a workflow
      • Can run serially or in parellel
      • An example might be a job that runs tests
    • Actions - Custom application that provides functionality, can write your own or use pre-built ones from the Marketplace
    • Step -
    • Runners - Server virtua/hosted/on-prem where the workflow is executed
    • Secrets - Sensitive environment variables like passwords, API keys, and tokens. GitHub provides a mechanism for securely secrets with your source code. Secrets can be stored at the organization, repository and environment level. Once created secrets can then be used in your workflows.
    • Environments - Are collections of settings (allowed branches, secrets, and protection rules.) An environment in GitHub likely correlates to the environment your workflow will act against.
      • By using a named environment secret you can have a single workflow file, that uses different secrets based on the environment the workflow is executed in.
• Quickstart - Create your first workflow
• Write your own action - Chances are you will not often need to do this, but understanding how the actions you are using a built will give you a better understanding of how to use them and why something might not work as expected.
• Continuous Integration - This will guide you in creating your first workflow.
• GitHub Script - Create a workflow that uses the GitHub script action (more about this below).

Tips, Resources, & Useful Actions

• GitHub Checkout Action - Checks your code out of your repo so it can be used in your workflow. Likely you will use this in most workflows.
• Terraform Setup - Sets up the terraform CLI making it easy to execute your IAC
• GitHub Cache Action - Allows you to cache artifacts across runs in the same branch. Useful to speed up your builds.
• GitHub Script Action - Exposes GitHub's RESTful APIs inside a Script block of a workflow "step". This is very useful for automations
  • RESTful API documentation - General API documentation
  • Octokit Documentation - NodeJS implementation of GitHub RESTful API.
• GitHub Action Org - Owner of all the GitHub developed repositories containing Actions related code
• GitHub Actions Documentation
• Starter/Template Workflows - Contains templated workflows for common tasks
• If you add a Repository Secret with the name ACTIONS_STEP_DEBUG and the value of 'true' this will turn on debugging logs for your Workflows.
• YAML is all about indentation, and it is easy to cause yourself headaches due to missing a space. Use a YAML linter like this for VSCode

Reusable Workflows and Custom NU Actions

Non-authoratative list of NUIT developed workflows and actions that perform common actions

• aws-secrets-sync-action Custom action to add secrets to AWS Parameter Store after successfully executing IAC
• ado-reusable-workflows-terraform Reusable workflow that performs the common steps of executing terraform IAC as part of a PR or Build process