Skip to the content.

Github Certification Exam Notes

Actions Overview

Great resources

Two types of actions

Actions Flow

image

Order of yaml file keywords (ex: on, push, jobs, runs-on, steps, uses, run)

Referencing and running actions

How to reference an action

steps:    
  # Reference a specific commit
  - uses: actions/setup-node@c46424eee26de4078d34105d3de3cc4992202b1e
  # Reference the major version of a release
  - uses: actions/setup-node@v1
  # Reference a minor version of a release
  - uses: actions/setup-node@v1.2
  # Reference a branch
  - uses: actions/setup-node@main

Environment Variables

To use a default environment variable, specify $ followed by the environment variable’s name. You can use defined variables as contexts. The $ tells GitHub to evaluate the statement as an expression instead of just a string. Notice default environment variables are all uppercase where context variables are all lowercase. You can also use custom environment variables in your workflow file. Also Default variables are case sensitive.

# This example is using the github.ref context to check the branch that triggered the workflow. If the branch is main, the runner is executed and prints out "Deploying to production server on branch $GITHUB_REF". The default environment variable $GITHUB_REF is used in the runner to refer to the branch. To create a custom variable (ex: First_Name), you need to define it in your workflow file using the env context.
name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

Glancing over these default environment variables to just know generally what exists and the naming convention that GitHub uses is helpful: https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables

Passing data between jobs

Using “upload-artifact” and “download-artifact” works well, or else using ::set-output ::.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

Workflow Triggers (Events to run an action)

Workflows can be configured to run:

Glancing over these event triggers to just know generally what exists and the naming convention that GitHub uses is helpful: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

Creating Actions

Metadata and syntax needed to create an action in a action.yml file:

Parameter Description Required
Name The name of your action. Helps visually identify the action in a job. yes
Description A summary of what your action does. yes
Inputs Input parameters enable you to specify data that the action expects to use during runtime. These parameters become environment variables in the runner. no
Outputs Output parameters enable you to specify data that subsequent actions can use later in the workflow after the action that defines these outputs has run. no
Runs The command to run when the action executes. yes
Branding Color and Feather icon to use to create a badge to personalize and distinguish your action in GitHub Marketplace. no

Manage github actions in the enterprise

Learning Module: https://docs.microsoft.com/learn/modules/manage-github-actions-enterprise

Self-Hosted vs GitHub-hosted runners

Secret Management

Secret management, specifically for enterprises, is important to know the scoping, that secrets go from Organization level, repository level, to environment level in decreasing levels.