YouTube Summaries | GitHub Actions Tutorial - From Zero to Hero in 90 Minutes

March 4th, 2024

Introduction:

This summary will serve to cement the learnings that I took from the video above, which is a tutorial that goes over using GitHub actions. It assumes no prior knowledge and aims to get the viewer to a functional status in 90 minutes. I hope you find it useful too!

Overview

GitHub Actions is a vital workflow automation feature in software development.

Covered Aspects

  1. Workflows: Workflows are a pivotal component in GitHub Actions, defined using YAML files.

  2. Actions Visualization: The Action Visualization feature proves valuable, displaying the sequence of actions and their associated parameters.

  3. Environments: Environments are introduced as tools for managing and visualizing deployments in different contexts.

  4. Hosted vs. Self-hosted Runners: Differences between hosted and self-hosted runners are outlined, emphasizing factors like maintenance, customization, and cost considerations.

  5. Runner Groups: We’ll touch upon the use of runner groups, explaining their purpose in organizing runners based on specific criteria.

  6. Secrets Management: GitHub Actions’ secrets management is highlighted, covering the use of secrets at different levels – organization, repository, and environment.

  7. Advanced Scenarios: Advanced scenarios are discussed, including custom parameters and conditionals, providing a glimpse into more intricate workflow configurations.

Workflows and Actions Visualization

  1. Overview of Visualization:

    • Actions Visualization is introduced as a feature providing a graphical representation of workflow execution.

  2. Visualizing Workflow Execution:

    • Users can visualize the sequence and execution status of actions in the GitHub Actions tab.
    • Each action is represented as a block, color-coded to denote success, failure, or other statuses.

  3. Interactive Features:

    • The URL specified in the workflow file can be accessed directly from the visualization, offering a seamless transition to the deployed environment or application.
    • Interactive links enable users to navigate between actions, enhancing the overall user experience.

  4. Home Page Integration:

    • Environments using Actions are seamlessly integrated into the home page of the repository, providing a comprehensive overview.
    • A new box displays all environments in the deployment order, highlighting the latest deployment state.

  5. Environment Dashboard:

    • Clicking on an environment leads to the Environment Dashboard, offering real-time insights into the state and activity log of each environment.

  6. Workflow Approval Process:

    • For deployments in the “waiting for review” state, GitHub Actions supports a review and approval process.
    • Reviewers can access the workflow, review changes, and either approve or reject the deployment to production.

  7. Runner Information in Visualization:

    • Runner information, including URLs and specific deployment details, is visible within the Actions Visualization.

  8. Enhanced User Interaction:

    • Users can directly click on links within the visualization to access the deployed environment or application.

  9. Advantages of Visualization:

    • The visualization offers practical advantages, such as easy navigation, deployment tracking, and streamlined approval processes.

  10. Integration with Secrets and Rules:

    • The visualization integrates with secrets and rules, enhancing security and governance during the workflow execution.

  11. Deployment Order and State:

    • Environments are listed in the deployment order, reflecting the latest deployment states and providing a clear overview.

  12. Customization and Recommendations:

    • Users are encouraged to provide meaningful comments during the approval process, enhancing communication and traceability.

  13. Self-hosted vs. Hosted Runners:

    • Maintenance and Updates:

      • Hosted runners are managed by GitHub, handling updates, maintenance, and governance automatically.
      • Self-hosted runners require user responsibility for updates, maintenance, and overall management.

    • Customization Capabilities:

      • Hosted runners provide a clean instance for each execution, limiting customizations.
      • Self-hosted runners offer extensive customization options, allowing users to install specific dependencies and tailor environments.

    • Recommendations and Use Cases:

      • Hosted runners are recommended for public repositories, ensuring a secure and controlled environment.
      • Self-hosted runners are suitable for scenarios like GPU computation or specific infrastructure requirements but are discouraged for public repositories due to potential security risks.

Environments and Deployments

  1. Introduction and Purpose:

    • Environments are introduced to GitHub Actions, representing target deployment environments such as development, staging, and production.
    • Purpose: Organize and manage workflows for different stages of development and deployment.

  2. Environment Configuration:

    • Environments can be configured in the repository settings, specifying a name, protection rules, and secrets.
    • Secrets associated with an environment override repo-level and organization-level secrets during deployment.

  3. Workflow Deployment:

    • Workflows include a on.environment event to trigger specific actions upon deployment to a particular environment.
    • Deployment jobs and steps can be configured to target specific environments.

  4. Visualization and Monitoring:

    • GitHub provides a visual representation of environments on the repository homepage.
    • The environment dashboard displays the latest state, an activity log, and facilitates easy navigation to deployed applications.

  5. Approval Workflows:

    • Environments can be set to require approval before deployment.
    • Reviewers with appropriate permissions can approve or reject deployments to ensure control and coordination.

  6. Hosted vs. Self-hosted Runners:

    • Both hosted and self-hosted runners can be used for environment deployments.
    • Considerations include maintenance, customization, and security, with self-hosted runners offering more control.

  7. Runner Groups:

    • Self-hosted runners can be organized into groups based on criteria like organization, technology, or team.
    • Runner groups enable better management and allocation of runners for different purposes.

  8. Secrets Management:

    • GitHub Actions supports secrets for secure credential storage.
    • Three levels of secrets: Organization, Repository, and Environment, each with different scopes and priorities.

  9. Limitations and Best Practices:

    • Public repositories are cautioned against using self-hosted runners due to potential security risks.
    • Best practices involve creating dedicated users, limited sudo access, and organizing runner pools based on application requirements.

  10. Advanced Scenarios:

    • Custom parameters and conditionals can be utilized in workflows for dynamic and conditional execution.
    • Automation includes using repository dispatch events and conditional statements for precise workflow control.

  11. API Integration:

    • GitHub Actions functionalities can be accessed and managed via APIs.
    • Automation possibilities extend to artifacts, workflow status, job information, and trigger actions using APIs.

Hosted vs. Self-hosted Runners

  1. Hosted Runners:

    • GitHub provides hosted runners that are maintained, updated, and managed by GitHub.
    • Automatic updates ensure the environment is clean for each workflow run.
    • Hosted runners are ephemeral, starting with a clean instance for each execution.
    • Ideal for quick, disposable tasks and standard use cases.
    • No user responsibility for maintenance, updates, or security governance.

  2. Self-hosted Runners:

    • Users manage and maintain self-hosted runners on their infrastructure.
    • Offers customization capabilities with specific tools, dependencies, and configurations.
    • Users need to handle runner maintenance, updates, and security.
    • Suitable for scenarios requiring persistent configurations, specialized tools, or specific runtime environments.
    • Can be beneficial when working with GPU computation or specialized hardware.

  3. Customization and Control:

    • Self-hosted runners allow customization of environments based on application needs.
    • Users can install dependencies, frameworks, and tools according to project requirements.
    • Provides more control over the environment’s permissions, network connections, and configurations.

  4. Runner Groups:

    • Runner groups can be created to organize self-hosted runners based on criteria like technology stack, teams, or organizational units.
    • Helps manage and allocate runners efficiently for different applications or purposes.
    • Each runner can belong to only one group at a time, offering clear categorization.

  5. Public Repositories Considerations:

    • Caution is advised when using self-hosted runners with public repositories.
    • Public repositories inherently expose code, and self-hosted runners might risk unintended access.
    • Recommendations include setting up IP allow lists and strong firewalls when using self-hosted runners with public repos.

  6. GPU Computation and Specialized Scenarios:

    • Self-hosted runners are valuable when working with GPU computation.
    • GitHub does not offer GPU hosted runners, necessitating the use of self-hosted runners for such scenarios.
    • Configuring self-hosted runners for specific tasks, such as GPU-related workloads, is a common use case.

  7. Installation and Configuration:

    • GitHub provides scripts and tools for registering self-hosted runners.
    • Users execute scripts on their dedicated machines, configuring runners to authenticate against the repository or organization.
    • Requires attention to dependencies, updates, and ensuring compatibility with the applications being built.

  8. Limitations:

    • Running GitHub Actions workflows inside Docker using self-hosted runners is not officially supported.
    • Limitations stem from the execution of Docker actions, which might conflict with certain GitHub Actions requirements.
    • Community workarounds exist, but the feature lacks official support as of the current implementation.

Runner Groups

  1. Organizing Runners Efficiently:

    • Runner groups serve as a mechanism to efficiently organize and manage self-hosted runners.
    • Useful for scenarios where runners need categorization based on specific criteria such as technology stack, teams, or organizational units.

  2. Pooling Runners for Different Teams or Technologies:

    • Allows grouping runners based on team-specific needs or technology requirements.
    • For example, one group might contain runners for Java applications, while another group houses runners configured for .NET projects.

  3. Avoiding Conflicts Between Runners:

    • Runner groups help prevent conflicts and interference between runners.
    • Runners within a group share common characteristics, minimizing potential issues arising from conflicting configurations.

  4. Scoping Runners to Specific Organizations or Repositories:

    • Provides the ability to scope runner groups to specific organizations or repositories.
    • Enables dedicated runner pools for distinct parts of an organization, ensuring separation and tailored environments.

  5. Flexibility in Runner Assignment:

    • Runner groups offer flexibility, allowing runners to be moved between groups as needed.
    • While individual runners are movable, each runner can belong to only one group at a time.

  6. Use Cases:

    • Large organizations with diverse teams benefit from runner groups by isolating runners for different departments or projects.
    • Separating runners by technology stack helps ensure that each group has the necessary tools and dependencies for specific frameworks.

  7. Enhanced Organization Dashboard:

    • Enhances the organization’s GitHub Actions dashboard by presenting a clearer view of runner groups.
    • Each group can be associated with specific characteristics, streamlining the selection of runners for workflows.

  8. Effective Resource Allocation:

    • Facilitates effective resource allocation by grouping runners based on shared requirements.
    • Reduces the risk of resource contention and ensures runners are dedicated to tasks aligned with their configurations.

  9. Configuration and Management:

    • Runner groups are configured through the GitHub interface, allowing easy creation and modification.
    • Management involves assigning runners to groups and ensuring each runner is aligned with the intended use case or project.

Secrets Management

  1. Types of Secrets:
  • GitHub Token: Automatically available to actions, providing access to the repository.
  • User-defined Secrets:
    • Organization Secrets: Scoped at the organizational level, available across repositories within the organization. Requires a paid plan.
    • Repository Secrets: Scoped at the repository level, available within a single repository. Accessible in both free and paid plans.
    • Environment Secrets: Specific to environments, overriding organization and repository secrets. Accessible by users with environment-specific permissions.

  1. Creation and Management:

    • Secrets are created and managed through the GitHub UI.
    • Each secret has a name, value, and scope (organization, repository, or environment).
    • Repository and organization secrets are limited to 100, and the size of each secret is capped at 64KB.
    • Secrets can be updated or removed, but their values are obscured for security.

  2. Visibility and Security:

    • Secret values are not visible in the UI, enhancing security.
    • Even during manual updates, values are replaced with stars to prevent inadvertent exposure.

  3. Forked Repositories and Secrets:

    • Forked repositories do not inherit secrets by default, except for private repositories where this can be enabled.
    • Public repository secrets are not forked to prevent unintended disclosure.

  4. Limitations and Workarounds:

    • Secret values cannot be read via APIs, limiting automated retrieval.
    • Workarounds for size limitations involve encrypting larger files and storing the encryption key as a secret.

  5. Integration with Third-Party Secrets Providers:

    • GitHub Actions does not directly integrate with third-party secrets providers like Azure Key Vault.
    • Third-party actions from the GitHub Marketplace offer solutions for fetching secrets from external providers.

  6. Security Measures:

    • Prevents secret leaks by obscuring values even during action execution logs.
    • Encourages users to follow best practices, such as avoiding exposing secrets in public repositories.

Advanced Scenarios

  1. Custom Parameters in Repository Dispatch:

    • Allows passing custom parameters when triggering workflows manually using the repository_dispatch event.
    • Parameters are specified in the client_payload section, providing flexibility in workflow customization.
    • Enables dynamic workflow executions based on custom input values.

  2. Conditional Execution with If Clauses:

    • Conditions can be applied at the action or job level to influence workflow execution.
    • Conditions support literals, variables, or output parameters from preceding jobs.
    • Enhances workflow flexibility by enabling conditional execution based on specific criteria.

  3. Integration with Third-Party Secrets Providers:

    • GitHub Actions lacks direct integration with third-party secrets providers like Azure Key Vault.
    • The GitHub Marketplace offers actions that facilitate the retrieval of secrets from external providers.
    • Provides a workaround for accessing external secrets while maintaining compatibility with GitHub Actions.

  4. Parameter Passing with Output Variables:

    • Enables passing information between jobs using output variables from preceding jobs.
    • Useful for scenarios where the outcome of one job influences subsequent job executions.
    • Enhances workflow logic by allowing dynamic decision-making based on the results of earlier job executions.

  5. Artifact Management:

    • Actions support the automation of artifact creation, retention, and usage.
    • Artifacts can be shared between jobs within a workflow or across different workflows.
    • Facilitates the seamless flow of data between workflow components, contributing to a well-orchestrated CI/CD process.

  6. Conditional Workflow Triggers:

    • Workflow triggers can be conditioned based on events or schedules.
    • Provides fine-grained control over when workflows are initiated, optimizing resource utilization.
    • Enables tailored workflow automation based on specific events or predefined schedules.

Example Events to Trigger On

  1. push: Triggered on code pushes to the repository.
  2. pull_request: Triggered when a pull request is opened, modified, or closed.
  3. pull_request_review: Triggered when a pull request review is submitted.
  4. pull_request_review_comment: Triggered when a comment on a pull request review is created.
  5. pull_request_target: Similar to pull_request, triggered on events against the base repository in a fork.
  6. create: Triggered when a new branch or tag is created.
  7. delete: Triggered when a branch or tag is deleted.
  8. repository_dispatch: Manually triggered events via the GitHub API or GitHub Actions workflows.
  9. workflow_run: Triggered at the completion of a workflow run.
  10. schedule: Triggered based on a specified schedule.
  11. check_run: Triggered when a check run is created, completed, or rerequested.
  12. check_suite: Triggered when a check suite is completed or requested.
  13. push_to_delete: Triggered when a branch is deleted via a force push.

Example Matrix Workflow

name: Matrix Build

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        os: [ubuntu-20.04, ubuntu-18.04]
        node: [14, 12]

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}

      - name: Install Dependencies
        run: npm install

      - name: Build and Test
        run: npm test

This example GitHub Actions workflow file demonstrates a matrix build configuration. It defines a job called “build” that runs on both Ubuntu 20.04 and 18.04, using Node.js versions 14 and 12. The workflow is triggered on pushes to the main branch. The steps include checking out the repository, setting up Node.js, installing dependencies, and running tests. The matrix strategy allows for parallel execution of the defined combinations.

Example Cron Job Workflow

name: Scheduled Job

on:
  schedule:
    - cron: "0 0 * * *" # Run daily at midnight UTC

jobs:
  cron:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v2

      - name: Run Cron Job
        run: |
          echo "This job runs daily as a scheduled cron job."

This GitHub Actions workflow file schedules a cron job to run daily at midnight UTC. The workflow includes a job named “cron” that runs on an Ubuntu environment. The steps involve checking out the repository and executing a simple command to indicate the execution of the cron job.