GitHub Actions exam Cheat Sheet -(part2)

GitHub Actions Workflows components:

• Actions: Reusable tasks that perform specific jobs within a workflow.
• Workflows: Automated processes in your repo that run one or more jobs, triggered by events or on a schedule.
• Jobs: Groups of steps that execute on the same runner, typically running in parallel unless configured otherwise.
• Steps: Individual tasks within a job that run commands or actions sequentially.
• Runs: Instances of workflow execution triggered by events, representing the complete run-through of a workflow.
• Runners: Servers that execute workflow jobs, either GitHub-hosted or self-hosted.
• Marketplace: A hub for sharing reusable actions, enhancing workflow abilities with community-developed tools.

GitHub Actions Usage Limits

• Max Job Execution Time: 6 hours
• Max Workflow Run Time: 35 days
• Max Job waiting for approval Time: 30 days
• Max API Requests: 1000 requests
• Max jobs generated by a matrix : 256 jobs (per workflow)
• Max artifact retention: 90 days
• Max Workflow time before deletion” More than two weeks ol
• Max unique reusable workflows call from a single workflow file: 20Job

Total Job limits

Structure

Name: Workflow name 
on: Events that trigger a workflow (push on the branch git_actions for any change in paths section)
env: Variables definition (hardcoded or imported from the environment such as secrets, vars)
Permissions: To allow your actions to use the token_id
Jobs section: JobName, runner OS (runs-on) , environment, default shell and working directory
Steps section: checkout your code repo + other steps(run tests, build artifacts..)
Same for the next job…

Workflow Triggers:

Basic Event Triggers:

Events Types:

Trigger Filtering & combinations

// 1. PUSH PULL REQUEST
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
    
// 1. Scheduled tasks
on:
  schedule:
    - cron: '0 0 * * *' # Daily at midnight    

// 3. Release
on:
  release:
    types: [published]

// 3.2 run when a push is made to any branch or when a branch or tag is created.

on: [push, create]

// 4. Manual trigger wit filters
on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'
// 4.2 use the GH API to trigger a webhook repository_dispatch event. 
##       
 on:
  repository_dispatch:
    types: [opened, deleted]

### call the run   
 curl \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/{owner}/{repo}/dispatches \
  -d '{"event_type":"event_type"}'       

#####################################################################
        
// 5.  Github actions check WebHook
# triggering a workflow to run on webhook events related to check_run actions
on:
  check_run:
    types: [created, completed]


// 6. Reusable workflow:           
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string     
        
// File change 
on:
  push:
    paths:
      - 'docs/**'
      - '*.md'
# This triggers the workflow when any file in the `docs` directory or any Markdown file (`.md`) is changed.
//   push with paths-ignore      
on:
  push:
    paths-ignore:
      - 'README.md'
      - 'build/**'   
      - '!build/docs/**'   
# * This triggers the workflow on any push *except* when only the `README.md` file or files in the `build` directory are changed. 

# When Issue comment is added
on:
  issue_comment:
    types: [created]      
                                                           
# IF condition to check if the github.ref (the branch or tag ref that triggered the workflow run) matches refs/heads/main.
name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      ...    
      
# Run when the workflow named Build runs on branch releases/:
 on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**' 
    branches-ignore:
      - "canary"                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

// 1. PUSH PULL REQUEST
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
    
// 1. Scheduled tasks
on:
  schedule:
    - cron: '0 0 * * *' # Daily at midnight    

// 3. Release
on:
  release:
    types: [published]

// 3.2 run when a push is made to any branch or when a branch or tag is created.

on: [push, create]

// 4. Manual trigger wit filters
on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'
// 4.2 use the GH API to trigger a webhook repository_dispatch event. 
##       
 on:
  repository_dispatch:
    types: [opened, deleted]

### call the run   
 curl \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/{owner}/{repo}/dispatches \
  -d '{"event_type":"event_type"}'       

#####################################################################
        
// 5.  Github actions check WebHook
# triggering a workflow to run on webhook events related to check_run actions
on:
  check_run:
    types: [created, completed]


// 6. Reusable workflow:           
on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string     
        
// File change 
on:
  push:
    paths:
      - 'docs/**'
      - '*.md'
# This triggers the workflow when any file in the `docs` directory or any Markdown file (`.md`) is changed.
//   push with paths-ignore      
on:
  push:
    paths-ignore:
      - 'README.md'
      - 'build/**'   
      - '!build/docs/**'   
# * This triggers the workflow on any push *except* when only the `README.md` file or files in the `build` directory are changed. 

# When Issue comment is added
on:
  issue_comment:
    types: [created]      
                                                           
# IF condition to check if the github.ref (the branch or tag ref that triggered the workflow run) matches refs/heads/main.
name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      ...    
      
# Run when the workflow named Build runs on branch releases/:
 on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**' 
    branches-ignore:
      - "canary"                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

Configure workflows to run for scheduled events

# run a workflow every 15 minutes on jan 31s if it's Saturday
on:
  schedule:
    - cron:  '*/15 * 31 JAN SAT'

# run a workflow every Sunday at 3:00am
on:
  schedule:
    - cron:  '0 3 * * SUN'

# run a workflow every 15 minutes on jan 31s if it's Saturday
on:
  schedule:
    - cron:  '*/15 * 31 JAN SAT'

# run a workflow every Sunday at 3:00am
on:
  schedule:
    - cron:  '0 3 * * SUN'

Delete Vs. Disable Workflow

Skip Workflow

You can Skip workflow runs by adding a keyword to the commit message or PR title. Use any of the following to the commit message in a push, or HEAD commit of a pull request:

[skip ci] [ci skip] [no ci] [skip actions] [actions skip]

[skip ci] [ci skip] [no ci] [skip actions] [actions skip]

Reusable workflows

workflow_call

Outputs from a reusable workflow or job need to be explicitly defined and passed using the correct syntax.
They are not automatically passed. Options to pass the files location (or other outputs) from a called workflow to the caller workflow are:

• Writing the output into $GITHUB_OUTPUT
• Defining an output at the workflow level
• Defining an output at the job level.

# .github/workflows/build.yml
name: Build
on:
  workflow_call:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2     
      - name: Create a zip file
        run: |
          echo "This is a zip file content" > output/sample.txt
          zip -r output/sample.zip output/
        
      - name: Set output for zip file location
        run: echo "zip_file=output/sample.zip" >> $GITHUB_OUTPUT

# .github/workflows/build.yml
name: Build
on:
  workflow_call:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2     
      - name: Create a zip file
        run: |
          echo "This is a zip file content" > output/sample.txt
          zip -r output/sample.zip output/
        
      - name: Set output for zip file location
        run: echo "zip_file=output/sample.zip" >> $GITHUB_OUTPUT

# .github/workflows/caller.yml
name: Caller Workflow
on:
  push:
    branches:
      - main
jobs:
  call-build:
    uses: ./.github/workflows/build.yml
    with:
      # Pass input parameters if needed

  use-output:
    runs-on: ubuntu-latest
    needs: call-build
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Access zip file location
        run: echo "The zip file location is: ${{ needs.call-build.outputs.zip_file }}"

# .github/workflows/caller.yml
name: Caller Workflow
on:
  push:
    branches:
      - main
jobs:
  call-build:
    uses: ./.github/workflows/build.yml
    with:
      # Pass input parameters if needed

  use-output:
    runs-on: ubuntu-latest
    needs: call-build
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Access zip file location
        run: echo "The zip file location is: ${{ needs.call-build.outputs.zip_file }}"

# 1. # Caller workflow
name: Caller Workflow
on:
  push:
    branches: [main]

permissions:
  contents: read  # Setting read permission for contents
  issues: write
jobs:
  call-reusable-workflow:
    uses: ./.github/workflows/reusable-workflow.yml
...

# 2.  # Reusable workflow (./.github/workflows/reusable-workflow.yml)
name: Reusable Workflow
on:
  workflow_call:

# This is valid - downgrading the permissions
permissions:
  contents: none  # Downgrading from read to none
  issues: read    # Downgrading from write to read

# 1. # Caller workflow
name: Caller Workflow
on:
  push:
    branches: [main]

permissions:
  contents: read  # Setting read permission for contents
  issues: write
jobs:
  call-reusable-workflow:
    uses: ./.github/workflows/reusable-workflow.yml
...

# 2.  # Reusable workflow (./.github/workflows/reusable-workflow.yml)
name: Reusable Workflow
on:
  workflow_call:

# This is valid - downgrading the permissions
permissions:
  contents: none  # Downgrading from read to none
  issues: read    # Downgrading from write to read

Workflow Concurrency

By default GHA allows multiple jobs or workflow runs to run concurrently. The concurrency keyword allows you to control the concurrency of workflow runs.

### workflow Level
on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

### workflow Level
on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

## Job level 
on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

## Job level 
on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

Exclude Branch Protection Deletion

on:
  branch_protection_rule:
    types: [created, edited] # (omit deleted).

on:
  branch_protection_rule:
    types: [created, edited] # (omit deleted).

Functions in GitHub Actions:

Status Check Functions:

- name: Run Tests
   id: run-tests
   run: npm run test

 - name: Upload Failure test report
   if: failure() && steps.run-tests.outcome == 'failure'   <----
   uses: actions/upload-artifact@v3
   with:
     name: test-report
     path: test-reports.html

- name: Run Tests
   id: run-tests
   run: npm run test

 - name: Upload Failure test report
   if: failure() && steps.run-tests.outcome == 'failure'   <----
   uses: actions/upload-artifact@v3
   with:
     name: test-report
     path: test-reports.html

GitHub actions Expression

• contains('hello world', 'hello') → Returns true
• startsWith('hello world', 'hello') → Returns true
• endsWith('hello world', 'world') → Returns true
• format('Hello {0} {1} {2}', 'Mona', 'the', 'Octocat')
• join(github.event.issue.labels.*.name, ', ')
• toJSON(obj), fromJSON(value)
• hashFiles('/Gemfile.lock', '/package-lock.json')

Checks API endpoint

GitHub Actions use Checks API to output statuses, results, and logs for a workflow.
GitHub uses webhooks to notify Actions of check events (i.e check_run), triggering workflows.

• Repo/org webhooks for check_run only receive created and completed event payloads
  • Other events/activity types : rerequested | requested_action
• When checks are set up, pull requests have a “Checks” tab for detailed build output and checks.

# triggering a workflow to run on webhook events related to check_run actions
on:
  check_run:
    types: [created, completed]  # activity types 

# triggering a workflow to run on webhook events related to check_run actions
on:
  check_run:
    types: [created, completed]  # activity types 

Caching & Artifacts

1. Artifacts:

Share outputs between jobs, retained for 90 days by default.

    uses: actions/upload-artifact@v4
    with:
      name: my-artifact
      path: my_file.txt
      retention-days: 5    <----------------

    uses: actions/upload-artifact@v4
    with:
      name: my-artifact
      path: my_file.txt
      retention-days: 5    <----------------

curl -L -H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/{owner}/{repo}/actions/artifacts/{artifact_id}
---
"expires_at": "2020-01-21T14:59:22Z"

curl -L -H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2022-11-28" \
https://api.github.com/repos/{owner}/{repo}/actions/artifacts/{artifact_id}
---
"expires_at": "2020-01-21T14:59:22Z"

2. Caching:

Stores dependencies to reduce workflow execution time.

• all branches can restore caches created on the default branch
• Purpose: improve efficiency, especially for feature branches.

GitHub Packages and Container Registry

Once published (in public or in private) you can use these images from anywhere, including:

• In your local dev environment
• As a base image from your GitHub Codespaces development environment
• As a step to execute into your workflow with GitHub Actions
• On a server or a cloud service

Features

• Package Container url: ghcr.io
• Example: docker pull ghcr.io/YOURNAME/publish-packages/game:TAG
• Authentication Requirements:
  • GitHub username
  • Personal Access Token (Classic) with read:packages scope
  • GitHub Packages endpoint
• Authenticate using a GitHub Actions workflow
  • use a GITHUB_TOKEN:
  • For package registries at PACKAGE-REGISTRY.pkg.github.com.
  • For the container registry at ghcr.io/OWNER/IMAGE-NAME.

GitHub Packages vs GitHub Releases

Packages published with GitHub inherit the visibility and permissions assigned at the repository level.

Publish GitHub Package using Workflow

1. Simple Package

 ...snipet
       uses: ruby/setup-ruby@v1   #Ruby
       with:
         bundler-cache: true

 publish-gpr: #Node
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 12
          registry-url: https://npm.pkg.github.com/
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}   #<---  authenticates to registry using GITHUB_TOKEN to publish the npm package

# npm ci ("CI) to install dependencies directly from the package-lock.json file, 
# as well as the tests for the project.
# workflow publishes the package to the registry-url: https://npm.pkg.github.com/ 

 ...snipet
       uses: ruby/setup-ruby@v1   #Ruby
       with:
         bundler-cache: true

 publish-gpr: #Node
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 12
          registry-url: https://npm.pkg.github.com/
      - run: npm ci
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}   #<---  authenticates to registry using GITHUB_TOKEN to publish the npm package

# npm ci ("CI) to install dependencies directly from the package-lock.json file, 
# as well as the tests for the project.
# workflow publishes the package to the registry-url: https://npm.pkg.github.com/ 

2. Docker based package

• Checkout: docker/login-action
• Extract metdata docker/metadata-action
• Setup Docker buildx (arm): docker/setup-buildx-action
• publish docker/build-push-action

echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
docker tag IMAGE_ID ghcr.io/OWNER/IMAGE_NAME:latest
docker push ghcr.io/OWNER/IMAGE_NAME:latest

echo $GITHUB_TOKEN | docker login ghcr.io -u USERNAME --password-stdin
docker tag IMAGE_ID ghcr.io/OWNER/IMAGE_NAME:latest
docker push ghcr.io/OWNER/IMAGE_NAME:latest

name: Create and publish a Docker image
on:
  push:
    branches: ['release']

env:
  REGISTRY: ghcr.io      <------- ${{ env.REGISTRY }}
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

name: Create and publish a Docker image
on:
  push:
    branches: ['release']

env:
  REGISTRY: ghcr.io      <------- ${{ env.REGISTRY }}
  IMAGE_NAME: ${{ github.repository }}

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Log in to the Container registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@9ec57ed1fcdbf14dcef7dfbe97b2010124a938b7
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

name: Release Workflow
on:
  push:
    tags:
      - 'v*'    <--------- trigger

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Build project
        run: |
          echo "Build your project here"
          # Example: gcc -o output_binary source_code.c
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false
      - name: Upload Release Asset
        uses: actions/upload-release-asset@v4
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./path/to/your/output_binary
          asset_name: output_binary_name
          asset_content_type: application/octet-stream

name: Release Workflow
on:
  push:
    tags:
      - 'v*'    <--------- trigger

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Build project
        run: |
          echo "Build your project here"
          # Example: gcc -o output_binary source_code.c
      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false
      - name: Upload Release Asset
        uses: actions/upload-release-asset@v4
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./path/to/your/output_binary
          asset_name: output_binary_name
          asset_content_type: application/octet-stream

Service Containers

SC are Docker containers that provide a simple and portable way to host services needed for testing or operating an application in a workflow.

name: Redis container example
on: push

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:16-bullseye    <-- parent container image
    services:
      redis:
        image: redis              < child container image

name: Redis container example
on: push

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:16-bullseye    <-- parent container image
    services:
      redis:
        image: redis              < child container image

name: Redis container example
on: push

jobs:
  runner-job:
    runs-on: ubuntu-latest
    services:
      redis:
        image: redis         <---- host container
        ports:
          - 6379:6379        <------For a runner job you need to map the ports.

name: Redis container example
on: push

jobs:
  runner-job:
    runs-on: ubuntu-latest
    services:
      redis:
        image: redis         <---- host container
        ports:
          - 6379:6379        <------For a runner job you need to map the ports.

name: "CodeQL"

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    cron: '0 14 * * 1'

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        language: ['java', 'javascript', 'python']

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v1
        with:
          languages: ${{ matrix.language }}
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v1

name: "CodeQL"

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    cron: '0 14 * * 1'

jobs:
  analyze:
    name: Analyze
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        language: ['java', 'javascript', 'python']

    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Initialize CodeQL
        uses: github/codeql-action/init@v1
        with:
          languages: ${{ matrix.language }}
      - name: Perform CodeQL Analysis
        uses: github/codeql-action/analyze@v1

jobs:
  build:
    services:
      redis:
        # Docker Hub image
        image: redis
        ports:
          - 6379:6379
        credentials:
          username: ${{ secrets.dockerhub_username }}
          password: ${{ secrets.dockerhub_password }}
      db:
        # Private registry image
        image: ghcr.io/octocat/testdb:latest
        credentials:
          username: ${{ github.repository_owner }}
          password: ${{ secrets.ghcr_password }}

jobs:
  build:
    services:
      redis:
        # Docker Hub image
        image: redis
        ports:
          - 6379:6379
        credentials:
          username: ${{ secrets.dockerhub_username }}
          password: ${{ secrets.dockerhub_password }}
      db:
        # Private registry image
        image: ghcr.io/octocat/testdb:latest
        credentials:
          username: ${{ github.repository_owner }}
          password: ${{ secrets.ghcr_password }}

# Running a Postgres server as a service container
jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

# Connecting the postgres service container in a step.
  steps:
    - name: Check out repository code
      uses: actions/checkout@v4
    - name: Install dependencies
      run: npm ci
    - name: Connect to PostgreSQL
      run: node client.js
      env:
        POSTGRES_HOST: postgres
        POSTGRES_PORT: 5432

# Running a Postgres server as a service container
jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432

# Connecting the postgres service container in a step.
  steps:
    - name: Check out repository code
      uses: actions/checkout@v4
    - name: Install dependencies
      run: npm ci
    - name: Connect to PostgreSQL
      run: node client.js
      env:
        POSTGRES_HOST: postgres
        POSTGRES_PORT: 5432

Runners

Runners: Logical grouping of execution environments

Self-Hosted Runners

• Must self-manage OS patching
• Free to use with GitHub Actions
• Shared environment for every job execution

Features:

• Flexible: Run on various hardware (physical, virtual, cloud, etc.).
• Levels: Can be set up at the repository, organization, or enterprise level.
• Enterprise-level runners can be assigned to multiple organizations in an enterprise account.
• Setup: Requires adding a runner and installing the GitHub Actions Runner software.
• Images: Supports macOS, Linux, and Windows operating systems.
• Architecture: Uses x64 architecture.

Restricting Actions

• Install with: npm install @actions/core @actions/github
• GitHub Enterprise can sync actions with: actions-sync
• Continuous sync with GH Connect

self hosted runners labels

A self-hosted runner automatically receives certain labels when it is added to GitHub Actions.

1. Default Labels

These are used to indicate its operating system and hardware platform:

• self-hosted: Default label applied to self-hosted runners.
• linux, windows, or macOS: Applied depending on operating system.
• x64, ARM, or ARM64: Applied depending on hardware architecture.

runs-on: self-hosted linux ARM64

runs-on: self-hosted linux ARM64

2. Custom Labels

• Create and assign custom labels to self-hosted runners to target specific types of runners for jobs.
• Cumulative: Runners must have all specified labels (including OS/architecture) to be eligible for a job.
• GPU is the custom label.

runs-on: self-hosted linux x64 gpu

runs-on: self-hosted linux x64 gpu

Runner groups

• Organize runners into sets and establish security boundaries.
• Availability: For enterprise, organizations within those accounts, and organizations using GitHub Team.
• Placement: New self-hosted runners are sent to default group and must be moved to the correct group manually.
• Labels and Groups can be combined when routing workflows to the appropriate runner.

name: learn-github-actions
on: push

jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners            <---- group
      labels: ubuntu-20.04-16core      <---- label within group

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

name: learn-github-actions
on: push

jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners            <---- group
      labels: ubuntu-20.04-16core      <---- label within group

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

Configure Self-hosted Runners for Enterprise

Self-hosted runners for GitHub Enterprise have additional configuration options.

Network requirement for github connectivity

• Permitting outbound connectivity from the runner to GitHub using long polling.
  • Self-hosted runners connect to GitHub to get jobs and download updates.
  • They use HTTPS long polling (50-second outbound connection, then reconnect).
  • ❌ Inbound to hosted runners isn’t required

Proxy Servers

IP Allowlists

A GitHub-hosted runner must establish connections to GitHub-owned endpoints to perform essential communication operations.
You must add the IP address or range of your self-hosted runners to the IP allowlist for communication to work between runners and GitHub workflows.

• Windows and Ubuntu runners are hosted in Azure same IP address ranges as Azure datacenters.
• MacOS runners are hosted in GitHub’s own macOS cloud.
• The list of GitHub Actions IP addresses returned by the API is updated once a week.
• Use larger runners with a static IP address range, or self-hosted runners.

Large Runners & IP Allowlists

• Large runners with static IPs ranges simplify allowlist management.
• Increased flexibility & isolation.
• Balances security & efficiency.

Monitor and troubleshoot self-hosted runners

# Networking check Example
./config.sh --check --url <URL> --pat ghp_abcd1234
# URL example https://github.com/octo-org/octo-repo

# Networking check Example
./config.sh --check --url <URL> --pat ghp_abcd1234
# URL example https://github.com/octo-org/octo-repo

Control access to self-hosted runners at the ORG and enterprise level:

• Enterprise Account: Go to Policies > Actions.
• Runner Groups Tab: Select “New runner group”.
• Configure: Set group name and organization access policy.
• Organization level Go To Settings>Actions > Select “New runner group”.

GitHub Actions commands, contexts & Variables

You can have repository, environment, as well as workflow, job, and step variable level.

1. Environment variables

2. Default Environment Variables

Default env variables that GitHub sets are available to every step in a workflow. Example: $GITHUB_RUN_ID. most of them are similar to context variables (GITHUB_REF=github.ref)

• Specify $ followed by the environment variable’s name.
• Are all uppercase.
• Most but not all have the prefix “GITHUB_”
• Available to every step in a workflow
• Are set by GitHub and not defined in a workflow
• ❌not accessible through the env context
• GITHUB_ACTIONS
• it always evaluates to true when GitHub Actions is running in the workflow

- run: echo "Deploying to production server on branch $GITHUB_REF"

- run: echo "Deploying to production server on branch $GITHUB_REF"

Workflow Defaults

# Add variable value for the current repository in an interactive prompt
$ gh variable set MYVARIABLE

# Read variable value from an environment variable
$ gh variable set MYVARIABLE --body "$ENV_VALUE"

# Read variable value from a file
$ gh variable set MYVARIABLE < myfile.txt

# Set variable for a deployment environment in the current repository
$ gh variable set MYVARIABLE --env myenvironment

# Set organization-level variable visible to both public and private repositories
$ gh variable set MYVARIABLE --org myOrg --visibility all

# Set organization-level variable visible to specific repositories
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3

# Set multiple variables imported from the ".env" file
$ gh variable set -f .env

# Add variable value for the current repository in an interactive prompt
$ gh variable set MYVARIABLE

# Read variable value from an environment variable
$ gh variable set MYVARIABLE --body "$ENV_VALUE"

# Read variable value from a file
$ gh variable set MYVARIABLE < myfile.txt

# Set variable for a deployment environment in the current repository
$ gh variable set MYVARIABLE --env myenvironment

# Set organization-level variable visible to both public and private repositories
$ gh variable set MYVARIABLE --org myOrg --visibility all

# Set organization-level variable visible to specific repositories
$ gh variable set MYVARIABLE --org myOrg --repos repo1,repo2,repo3

# Set multiple variables imported from the ".env" file
$ gh variable set -f .env

3. Environment Files

• Intra-job env: You can share custom env-variables with following steps in a workflow job by defining or updating the env-variable into the GITHUB_ENV environment file.
  • echo "{environment_variable_name}={value}" >> "$GITHUB_ENV"
• Between jobs/workflows you will need GITHUB_OUTPUT

Environment variables files Examples

# Set Env Vars
steps:
  - name: Set environment variable
    run: echo "ACTION_ENV=production" >> $GITHUB_ENV

# Adding custom path to System Path
steps:
  - name: Add directory to PATH
    run: echo "/path/to/dir" >> $GITHUB_PATH

# Setting Output Parameters
steps:
  - name: Set output
    id: example_step
    run: echo "result=output_value" >> $GITHUB_OUTPUT
  - name: Use output
    run: echo "The output was ${{ steps.example_step.outputs.result }}"

# Creating Debugging Messages
steps:
  - name: Create debug message
    run: echo "::debug::This is a debug message"

# Set Env Vars
steps:
  - name: Set environment variable
    run: echo "ACTION_ENV=production" >> $GITHUB_ENV

# Adding custom path to System Path
steps:
  - name: Add directory to PATH
    run: echo "/path/to/dir" >> $GITHUB_PATH

# Setting Output Parameters
steps:
  - name: Set output
    id: example_step
    run: echo "result=output_value" >> $GITHUB_OUTPUT
  - name: Use output
    run: echo "The output was ${{ steps.example_step.outputs.result }}"

# Creating Debugging Messages
steps:
  - name: Create debug message
    run: echo "::debug::This is a debug message"

4. Contexts

Context is a collection of variables describing workflow runs, runner environments, jobs, steps, secrets & much more.

• Provide a way to access information about various aspects of your workflow execution.
• Context environment variables are prefixed with "context.variable": i.e ${{ github.sha }}

Default Env. vs. Context Vars:

• Default Environment vars : runner scope
• Context vars: workflow scope.

# if statement with context
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'    # check if triggered on the main branch
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

# if statement with context
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'    # check if triggered on the main branch
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

# Example using secrets context
steps:
  - name: Use Secret as Env Var
    run: echo "Secret Value: $MY_SECRET"
    env:
      MY_SECRET: ${{ secrets.MY_SECRET }}
      My_TOK: ${{ secrets.GITHUB_TOKEN }}
      
 ### Interpolating variables  is done with
 ${{ variable }} — the spaces are mandatory. 

# Example using secrets context
steps:
  - name: Use Secret as Env Var
    run: echo "Secret Value: $MY_SECRET"
    env:
      MY_SECRET: ${{ secrets.MY_SECRET }}
      My_TOK: ${{ secrets.GITHUB_TOKEN }}
      
 ### Interpolating variables  is done with
 ${{ variable }} — the spaces are mandatory. 

GitHub Actions Security (Secrets)

• GitHubActions secrets store sensitive info passwords, API keys, tokens etc.
• maximum secret size 48 KB
• There are organization, repository and environment level secrets.
• In case of conflict, organization is overridden by repository–and repo is overridden by env values.
  • Secret names are not case-sensitive, & must be unique within the same level.
  • Secret names only contain alphanum characters and '_' and can’t contain spaces
  • Secret names must not begin with the prefix GITHUB_. & must not start with numbers
• secrets.GITHUB_TOKEN is a temporary token automatically generated for each workflow run.

GitHub Actions Commands

Customize runner environment

Commands prefixed with the :: can customize the runner environment, i.e set env variables or modify the working directory

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
      - name: Set Environment Variable
        run: echo "::set-env name=MY_VAR::my_value"
        
       - name: Change Working Directory
        run: |
          echo "::cd::$GITHUB_WORKSPACE/my_directory" # Change to the new directory        

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
      - name: Set Environment Variable
        run: echo "::set-env name=MY_VAR::my_value"
        
       - name: Change Working Directory
        run: |
          echo "::cd::$GITHUB_WORKSPACE/my_directory" # Change to the new directory        

if condition:
my-job:
  if: ${{ vars.MY_VAR == 'MY_VALUE' }}

if condition:
my-job:
  if: ${{ vars.MY_VAR == 'MY_VALUE' }}

jobs:
  example-job:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./scripts
    steps:
      - name: Check out the repository to the runner
        uses: actions/checkout@v4
      - name: Run a script
        run: ./my-script.sh    <---------- run script
      - name: Run another script
        run: ./my-other-script.sh <-------- runs script

jobs:
  example-job:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./scripts
    steps:
      - name: Check out the repository to the runner
        uses: actions/checkout@v4
      - name: Run a script
        run: ./my-script.sh    <---------- run script
      - name: Run another script
        run: ./my-other-script.sh <-------- runs script

GitHub Actions Workflow commands

workflow commands provided by the actions/toolkit allow to send instructions to runner.

• Can Create error annotations, set env vars, print debug messages.
• No workflow code modification needed.

##############################
# 1.Setting Output Parameters#
##############################
steps:
  - name: Set output
    id: example_step
    run: echo "result=output_value" >> $GITHUB_OUTPUT
  - name: Use output
    run: echo "The output was ${{ steps.example_step.outputs.result }}"

# Creating Debugging Messages
steps:
  - name: Create debug message
    run: echo "::debug::This is a debug message"

############################## 
# 2. Grouping Log Messages   #
##############################
steps:
  - name: Group log messages
    run: |
      echo "::group:: My Grouped Messages"
      echo "Message 1"
      echo "Message 2"
      echo "::endgroup::"

# Masking Values in Logs
steps:
  - name: Masking value
    run: echo "::add-mask::${{ secrets.SECRET_VALUE }}"

# Stopping and Failing Actions
steps:
  - name: Fail workflow
    run: echo "::error:: This is an error message"

##############################
# 1.Setting Output Parameters#
##############################
steps:
  - name: Set output
    id: example_step
    run: echo "result=output_value" >> $GITHUB_OUTPUT
  - name: Use output
    run: echo "The output was ${{ steps.example_step.outputs.result }}"

# Creating Debugging Messages
steps:
  - name: Create debug message
    run: echo "::debug::This is a debug message"

############################## 
# 2. Grouping Log Messages   #
##############################
steps:
  - name: Group log messages
    run: |
      echo "::group:: My Grouped Messages"
      echo "Message 1"
      echo "Message 2"
      echo "::endgroup::"

# Masking Values in Logs
steps:
  - name: Masking value
    run: echo "::add-mask::${{ secrets.SECRET_VALUE }}"

# Stopping and Failing Actions
steps:
  - name: Fail workflow
    run: echo "::error:: This is an error message"

Jobs

Jobs have something called dependence that allows the to run in a certain order.

jobs:
  job1:
    # ... job1 steps ...
  job2:
    needs: job1
    # ... job2 steps ...
  job3:
    needs: [job1, job2]
    # ... job3 steps ...

jobs:
  job1:
    # ... job1 steps ...
  job2:
    needs: job1
    # ... job2 steps ...
  job3:
    needs: [job1, job2]
    # ... job3 steps ...

jobs:
  job1:
    # ... job1 steps ...
  job2:
    needs: job1
    # ... job2 steps ...
  job3:
    if: ${{ always() }}               <--- runs no matter what
    needs: [job1, job2]
    # ... job3 steps ...

jobs:
  job1:
    # ... job1 steps ...
  job2:
    needs: job1
    # ... job2 steps ...
  job3:
    if: ${{ always() }}               <--- runs no matter what
    needs: [job1, job2]
    # ... job3 steps ...

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]
        ## total jobes 3 x 2 = 6
        

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]
        ## total jobes 3 x 2 = 6
        

jobs:
  matrix-job:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        pet: [cat, dog]
        color: [pink, brown]
        include:                   <---- addition not replacement 
          - color: white
            pet: dog
    steps:
      - run: echo "Hello ${{ matrix.color }} ${{ matrix.pet }}"

jobs:
  matrix-job:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        pet: [cat, dog]
        color: [pink, brown]
        include:                   <---- addition not replacement 
          - color: white
            pet: dog
    steps:
      - run: echo "Hello ${{ matrix.color }} ${{ matrix.pet }}"

Public GitHub Actions

How to vet a public action:

• Check if the action is in the GitHub Marketplace.
• Check if the action is verified in the GitHub Marketplace.
• Review the action’s action.yml file to make sure the code does what it says it does.

Publish an action to the GitHub Marketplace

Below requirements apply to both Docker container actions and JavaScript-based actions:

Actions Versioning

![example workflow](https://github.com/github/docs/actions/workflows/main.yml/badge.svg)

![example workflow](https://github.com/github/docs/actions/workflows/main.yml/badge.svg)

Benefits of automated release process

• Security Focus: Dependencies committed ONLY on tagged releases.
• Secure Builds: Builds performed ONLY during release.

Version calling

You can include version of the action in several ways by specifying a Git ref, SHA, tag, or branch.

 
 # Reference a specific #SHA commit
 steps:
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    
    # Reference the major version of a release
  steps:
    - uses: actions/checkout@v4                # Major version
    
    # Reference a specific version
  steps:
    - uses: actions/checkout@v4.2.0            # Specific version
    
    # Reference a branch
  steps:
    - uses: actions/checkout@main              # Branch

 
 # Reference a specific #SHA commit
 steps:
    - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
    
    # Reference the major version of a release
  steps:
    - uses: actions/checkout@v4                # Major version
    
    # Reference a specific version
  steps:
    - uses: actions/checkout@v4.2.0            # Specific version
    
    # Reference a branch
  steps:
    - uses: actions/checkout@main              # Branch

- uses: actions/checkout
Error: .github#L1 the `uses' attribute must be a path, a Docker image, or owner/repo@ref

- uses: actions/checkout
Error: .github#L1 the `uses' attribute must be a path, a Docker image, or owner/repo@ref

GitHub Action Types

1. JavaScript Actions

• Runs directly on the runner machine (Host OS)
• Separates action code from the environment
• Supports Windows, macOS, and Linux
• JavaScript action runs as a single Node.js process in the runner.

JavaScript Action Structure

  name: 'My JavaScript Action'
  description: 'A description of your action'
  inputs:
    my-input:
      description: 'Input to use in the action'
      required: true
      default: 'default input value'
  outputs:
    my-output:
      description: 'Output from the action'
  runs:
    using: 'node12'      <------- Executor 
    main: 'index.js'    <------------- main Action code file.

  name: 'My JavaScript Action'
  description: 'A description of your action'
  inputs:
    my-input:
      description: 'Input to use in the action'
      required: true
      default: 'default input value'
  outputs:
    my-output:
      description: 'Output from the action'
  runs:
    using: 'node12'      <------- Executor 
    main: 'index.js'    <------------- main Action code file.

const core = require('@actions/core');
const github = require('@actions/github');

try {
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput("time", time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

const core = require('@actions/core');
const github = require('@actions/github');

try {
  // `who-to-greet` input defined in action metadata file
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = (new Date()).toTimeString();
  core.setOutput("time", time);
  // Get the JSON webhook payload for the event that triggered the workflow
  const payload = JSON.stringify(github.context.payload, undefined, 2)
  console.log(`The event payload: ${payload}`);
} catch (error) {
  core.setFailed(error.message);
}

npm i -g @vercel/ncc
ncc build index.js --license licenses.txt
# You'll see a new dist/index.js file with your code and the compiled modules.
Change the main keyword in your action.yml file to use the new dist/index.js file.
main: 'dist/index.js'

npm i -g @vercel/ncc
ncc build index.js --license licenses.txt
# You'll see a new dist/index.js file with your code and the compiled modules.
Change the main keyword in your action.yml file to use the new dist/index.js file.
main: 'dist/index.js'

2. Docker container Actions

• Runs your action code in a Docker container. Best suited for an Action that requires a specific Linux OS and custom tools to run.
• Debug: for detailed information about the execution of the Docker container action, check the GitHub Actions logs.
• Must use Linux runners and have Docker installed

Docker Action Structure

name: 'My Docker Action'
description: 'A description of your action'
inputs:
  my-input:
    description: 'Input to use in the action'
    required: true
    default: 'default input value'
outputs:
  my-output:
    description: 'Output from the action'
runs:
  using: 'docker'
  image: 'Dockerfile'
  entrypoint: 'entrypoint.sh'
  post: 'cleanup.sh'    <---- cleanup script after the main task has finished.

name: 'My Docker Action'
description: 'A description of your action'
inputs:
  my-input:
    description: 'Input to use in the action'
    required: true
    default: 'default input value'
outputs:
  my-output:
    description: 'Output from the action'
runs:
  using: 'docker'
  image: 'Dockerfile'
  entrypoint: 'entrypoint.sh'
  post: 'cleanup.sh'    <---- cleanup script after the main task has finished.

#!/bin/sh
echo "My input: $INPUT_MYINPUT"
# ... your code here ...
echo "::set-output name=my-output::my-output-value"

#!/bin/sh
echo "My input: $INPUT_MYINPUT"
# ... your code here ...
echo "::set-output name=my-output::my-output-value"

name: Verify Docker Action Env

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Run Docker Container Action and Verify Env
      uses: docker://my-dockerhub-user/my-action:latest   <-------
      env:
        MY_ACTION_VAR: "Action Special Value"
      with:
        entrypoint: /bin/bash # Override entrypoint to run a shell command
        args: -c "echo '--- Environment Variables in Action Container ---';\
         env; echo '--- End ---'"

name: Verify Docker Action Env

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v4
    - name: Run Docker Container Action and Verify Env
      uses: docker://my-dockerhub-user/my-action:latest   <-------
      env:
        MY_ACTION_VAR: "Action Special Value"
      with:
        entrypoint: /bin/bash # Override entrypoint to run a shell command
        args: -c "echo '--- Environment Variables in Action Container ---';\
         env; echo '--- End ---'"

Manage GitHub Actions in the Enterprise

Synchronizing GH entreprise with Github Actions

Enterprise GitHub Actions standards

Policies

To configure a GitHub Actions use policy for your enterprise. Go to your enterprise account under Policies > Actions in the sidebar.

The following options should appear:

Granular selection within Enterprise repo:

You can set: Enterprise Server to automatically access the public actions available in the GitHub and to configure a use policy for them.
You can also manually download and sync actions into your enterprise instance using the actions-sync tool.

Enterprise GitHub Secrets

Organization Secrets:

• Organization Settings > Secrets and variables > Actions > New organization secret.
• Name, value, repository access policy.

inputs:
  super_secret:
    description: 'My secret token'
    required: true

inputs:
  super_secret:
    description: 'My secret token'
    required: true

Workflow Templates

Is an Enterprise feature that allows to create reusable templates that other enterprises members can use.

• Store workflow and metadata files in .github/workflow-templates
• workflow-templates should be within a repository named .github
• Use $default-branch placeholder for flexibility
• Metadata file format: <WF_FILE_NAME>.properties.json
• Users with write access to the enterprise.github repo can use them.
• Files must have the same name (e.g., my-workflow.yml and my-workflow.json).

Best Practice :

Create a dedicated repository to store and manage all reusable workflows.

1. YAML Workflow File:
   • Define workflow logic.
   • Use $default-branch placeholder.
2. JSON Metadata File:
   • Same filename as YAML, .properties.json extension.
3. Place both files in .github/workflow-templates in a public repo.

Example

name: Octo Organization CI

on:
  push:
    branches: ${default-branch}
  pull_request:
    branches: ${default-branch}

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run a one-line script
        run: echo Hello from Octo Organization

name: Octo Organization CI

on:
  push:
    branches: ${default-branch}
  pull_request:
    branches: ${default-branch}

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run a one-line script
        run: echo Hello from Octo Organization

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

Template Access & Usage:

• Actions > New workflow > Workflows created by [org name].
• Select from listed Workflows by clicking on > Set up this workflow

Starter Workflow

Starter Workflow is a pre-defined, customizable GitHub Actions workflow template provided by GitHub or organizations to help users quickly set up CI/CD automation for various languages, tools, and use cases.

GitHub Actions UI

When looking at workflow runs in the GitHub Actions GUI, you’ll typically find these status filters:

How to share a workflow log with the team:

click on the step’s line number to get a link to the specific line and share the link with a colleague

Static Code Analysis

🙋🏻‍♀️If you like this content please subscribe to our blog newsletter ❤️.