zircote

Comprehensive Overview of Actions, Workflows, Security, and Automation

Robert Allen 2025-12-29

::: notes Today we’ll explore the comprehensive GitHub ecosystem and how it provides enterprise-grade DevOps capabilities that transform software delivery. This presentation covers the many tools, patterns, and best practices that make GitHub the center of modern development workflows. :::

Executive Summary

The Modern Software Delivery Challenge

“Organizations need to deliver secure, reliable software faster than ever while managing increasing complexity”

::: notes Modern software organizations face unprecedented challenges. The toolchain sprawl, security threats, and need for compliance create a perfect storm that requires systematic solutions. :::

GitHub Ecosystem: Unified Platform

One Platform, Complete Capability The GitHub ecosystem provides integrated tools for:

::: notes GitHub evolved from a simple Git hosting platform to a comprehensive DevOps ecosystem. Every tool is deeply integrated, sharing authentication, permissions, audit logs, and APIs. :::

Key Metrics

::: notes GitHub’s scale demonstrates its industry dominance. The network effects and ecosystem maturity make it the de facto standard for software development. :::

GitHub Actions: CI/CD Foundation

What Are GitHub Actions?

Native CI/CD and Automation Engine GitHub Actions is an event-driven automation platform that runs workflows directly in your repository:

::: notes GitHub Actions transformed GitHub from a code hosting platform to a complete DevOps solution. The tight integration with repositories means zero external configuration. :::

Basic Workflow Structure

name: CI Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  contents: read
  pull-requests: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test
      - name: Build
        run: npm run build

::: notes This minimal example demonstrates the elegance of GitHub Actions. Everything is declarative, version-controlled, and reviewable through PRs. :::

Workflow Triggers: Event-Driven Automation

Conditional Execution: Use if conditions to control when jobs run ::: columns :::: column

Code Events

::: notes The rich set of triggers enables reactive and proactive automation. Schedule workflows for nightly builds, trigger on external webhooks for GitOps, or combine events for complex scenarios. :::

Matrix Builds: Test at Scale

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node: [18, 20, 22]
        include:
          - os: ubuntu-latest
            node: 22
            experimental: true
      fail-fast: false
    runs-on: $
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: $
      - run: npm test

::: notes Matrix builds explode a single job definition into multiple parallel executions. This example creates 9 test jobs (3 OS × 3 Node versions) automatically. :::

Reusable Workflows: DRY Principle for CI/CD

The Problem: Workflow Duplication

Before Reusable Workflows:

::: notes Every organization had dozens of nearly-identical workflow files. Updating a security practice meant manually editing hundreds of files across repos. :::

Reusable Workflows: Write Once, Use Everywhere

# .github/workflows/reusable-test.yml
name: Reusable Test Workflow

on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
      coverage-threshold:
        required: false
        type: number
        default: 80
    secrets:
      CODECOV_TOKEN:
        required: true

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: $
      - run: npm test
      - run: npm run coverage

::: notes Reusable workflows use the workflow_call trigger. They accept inputs for parameterization and can require secrets. This creates a library of composable automation. :::

Calling Reusable Workflows

# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  test-node-18:
    uses: org/central-workflows/.github/workflows/reusable-test.yml@v1
    with:
      node-version: '18'
      coverage-threshold: 85
    secrets:
      CODECOV_TOKEN: $

  test-node-20:
    uses: org/central-workflows/.github/workflows/reusable-test.yml@v1
    with:
      node-version: '20'

::: notes Calling workflows is clean and declarative. Reference by repo path and version tag. Organizations create shared workflow repositories that all projects consume. :::

Reusable Workflows: Benefits

ROI: Organizations report 70-90% reduction in workflow maintenance time ::: columns :::: column

Technical Benefits

::: notes The DRY principle applied to CI/CD creates massive leverage. Platform teams can maintain the automation library while product teams consume it. :::

Security Best Practices

Supply Chain Security: The Critical Challenge

Recent Incidents:

::: notes Supply chain attacks on CI/CD pipelines are the new frontier. Attackers target the development infrastructure because it has access to secrets, cloud credentials, and production deployment capabilities. :::

SHA Pinning: Immutable Dependencies

The Problem with Version Tags: The Solution: SHA Pinning: Benefits:

::: notes SHA pinning is now considered essential security hygiene. GitHub’s 2025 policy updates allow organizations to enforce SHA pinning across all repositories. :::

Automating SHA Pinning

Manual pinning doesn’t scale

- name: Pin Actions
  run: |
    npx pin-github-action \
      .github/workflows/*.yml
    
- name: Commit changes
  run: |
    git commit -am "security: pin actions"
    git push

::: columns :::: column

Tools for Automation

::: notes Organizations with hundreds of repositories need automation. These tools convert tag references to SHAs and keep them updated as new versions release. :::

OIDC: Eliminate Long-Lived Secrets

The Old Way: Stored Credentials Problems:

::: notes Traditional approaches store cloud credentials in GitHub Secrets. If an attacker compromises your workflow, they get permanent access. :::

OIDC: Short-Lived JWT Tokens

The Modern Way: OpenID Connect Benefits:

jobs: deploy: steps: - name: Configure AWS uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::ACCOUNT:role/GitHubActionsRole aws-region: us-east-1

  - name: Deploy
    run: aws s3 sync ./build s3://bucket ```

::: notes OIDC leverages GitHub’s identity provider to grant temporary credentials. Your cloud provider trusts token.actions.githubusercontent.com and issues short-lived credentials based on repository, branch, and environment. :::

OIDC Trust Configuration

Cloud Provider Setup (AWS Example):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::ACCOUNT:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main"
      }
    }
  }]
}

::: notes The trust policy explicitly lists which repositories, branches, and environments can assume the role. This provides defense-in-depth: even if an attacker compromises your workflow, they can’t access production without the right repository context. :::

Additional Security Hardening

Secret Scanning

::: notes Security is layered. Beyond SHA pinning and OIDC, restrict token permissions, validate inputs, and enable secret scanning to catch accidental credential leaks. :::

Repository Ecosystem Components

Content Pipeline Architecture

Automated Content Generation and Publishing This repository demonstrates a sophisticated content automation system:

::: notes This website isn’t just a Jekyll site. It’s a full content management system built on GitHub Actions, demonstrating how to automate the entire content lifecycle. :::

Workflow: Calendar-Driven Content

# .github/workflows/calendar-check.yml
name: Calendar Check

on:
  schedule:
    - cron: '0 9 * * 1'  # Monday 9am UTC
  workflow_dispatch:

jobs:
  check-calendar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Parse quarterly calendar
        run: node scripts/parse-calendar.js calendar/2026/
      
      - name: Create reminder issues
        run: |
          # Creates GitHub issues for content due in next 7 days
          node scripts/create-reminder-issues.js

::: notes The calendar-check workflow runs weekly, parsing YAML calendar files and creating GitHub issues as reminders for upcoming content deadlines. This bridges planning and execution. :::

Workflow: Scheduled Publishing

# .github/workflows/scheduled-publish.yml
name: Scheduled Publish

on:
  schedule:
    - cron: '5 0 * * *'  # Daily at 00:05 UTC

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Find posts to publish
        run: |
          # Find posts with date <= today and published: false
          node scripts/find-posts-to-publish.js
      
      - name: Update frontmatter
        run: |
          # Set published: true
          node scripts/update-frontmatter.js
      
      - name: Commit and push
        run: |
          git config user.name "GitHub Actions"
          git commit -am "chore: publish scheduled posts"
          git push

::: notes Content creators write posts in advance with published: false. The scheduled-publish workflow automatically enables them on the target date. This enables content batching and strategic timing. :::

Workflow: Content Validation

Multi-Stage Validation Pipeline Fail Fast: PRs cannot merge if validation fails

jobs:
  lint:
    runs-on: ubuntu-latest
  check-links:
    runs-on: ubuntu-latest
  validate-frontmatter:
    runs-on: ubuntu-latest
  validate-seo:
    runs-on: ubuntu-latest
  spell-check:
    runs-on: ubuntu-latest

::: columns :::: column

Checks Performed

::: notes The validate-content workflow runs on every PR and ensures content meets quality standards. This prevents broken links, malformed frontmatter, and SEO issues from reaching production. :::

Presentation Generation System

From Issue to Slide Deck The presentation generation workflow demonstrates advanced GitHub Actions patterns:

  1. Issue-Driven Creation - Presentation requests via GitHub Issue templates
  2. AI-Powered Content - Optional web research and repository analysis
  3. Multi-Format Output - PDF, PowerPoint, HTML (Reveal.js), Markdown
  4. Style System - Multiple design templates
  5. Automated PR - Generated presentations committed via PR

::: notes This very presentation was generated through that system. The issue specifies requirements, the workflow generates content, and outputs multiple formats for different contexts. :::

Presentation Workflow Architecture

# .github/workflows/presentation-from-issue.yml
on:
  issues:
    types: [opened]

jobs:
  generate:
    if: contains(github.event.issue.labels.*.name, 'presentation')
    steps:
      - name: Parse issue
        run: node scripts/parse-presentation-issue.js
      
      - name: Research content
        if: inputs.enable-research
        run: |
          # Web search, repository analysis
          node scripts/research-content.js
      
      - name: Generate slides
        run: |
          python docs/presentations/generate.py \
            --input drafts/output.md \
            --formats pdf,pptx,html \
            --style systematic-velocity
      
      - name: Create PR
        run: gh pr create

::: notes The workflow parses structured data from GitHub Issues, optionally performs research, generates content, produces multiple output formats, and opens a PR for review. This eliminates manual busywork. :::

Project Ecosystem Tools

swagger-php: OpenAPI Documentation

PHP Library for API Documentation Key Features: PHP 8 attributes, OpenAPI 3.x, framework-agnostic, 5,000+ GitHub stars

#[OA\Info(title: "My API", version: "1.0")]
class OpenApi {}

#[OA\Get(
    path: "/users/{id}",
    summary: "Get user by ID",
    tags: ["users"]
)]
#[OA\Parameter(
    name: "id",
    in: "path",
    required: true,
    schema: new OA\Schema(type: "integer")
)]
#[OA\Response(
    response: 200,
    description: "User found",
    content: new OA\JsonContent(ref: "#/components/schemas/User")
)]
public function getUser(int $id): User {}

::: notes swagger-php generates OpenAPI specifications from PHP annotations and attributes. It’s the de facto standard for PHP API documentation, used by Laravel, Symfony, and major PHP frameworks. :::

git-adr: Architecture Decision Records

ADRs in Git Notes, Not Files Advantages:

AI-assisted drafting

git adr draft “We need to choose a message queue”

Search decisions

git adr search “database”

List all ADRs

git adr list

Export to markdown

git adr export docs/adr/


::: notes
Traditional ADR tools create numbered markdown files in your repo. git-adr uses git notes instead, keeping decisions attached to the repository without polluting the file tree.
:::

---

## git-notes-memory: Semantic Memory for Claude Code

**Persistent Memory Across Sessions**
**Architecture:**
```bash
# Store a learning
git memory add "Use JWT for authentication in this project"

# Semantic search
git memory search "authentication"

# Inject context into Claude session
git memory recall | claude --context

┌─────────────────┐
│  Claude Code    │───▶ Memory Hooks ───▶ Git Notes
└─────────────────┘           │
                              │
                      ┌───────▼────────┐
                      │ Vector Index   │
                      │ (SQLite + FTS) │
                      └────────────────┘

::: notes Claude Code sessions are stateless by default. git-notes-memory provides persistent, searchable memory using git notes as storage. The vector index enables semantic search across learnings. :::

claude-spec: Project Planning Plugin

Structured Planning and Implementation Workflow | Command | Purpose | |———|———| | /cs:p <idea> | Plan new project with Socratic elicitation | | /cs:i <project> | Track implementation progress | | /cs:s | View status of all projects | | /cs:c <project> | Complete and archive project | Artifacts Generated:

::: notes claude-spec brings product management rigor to AI-assisted development. The plugin guides requirements gathering, generates planning documents, and tracks implementation across sessions. :::

vscode-git-adr: Visual Studio Code Extension

IDE Integration for ADRs

::: notes The VS Code extension brings ADR management directly into the development environment. Developers can create and reference architectural decisions without leaving their editor. :::

CI/CD Pipeline Patterns

Monorepo Pipeline Pattern

Selective Build and Test

name: Monorepo CI

on: [push, pull_request]

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      api: $
      web: $
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@v2
        id: changes
        with:
          filters: |
            api:
              - 'packages/api/**'
            web:
              - 'packages/web/**'
  
  build-api:
    needs: detect-changes
    if: needs.detect-changes.outputs.api == 'true'
    runs-on: ubuntu-latest
    steps:
      - run: npm run build:api
  
  build-web:
    needs: detect-changes
    if: needs.detect-changes.outputs.web == 'true'
    runs-on: ubuntu-latest
    steps:
      - run: npm run build:web

::: notes Monorepo pipelines need intelligent change detection to avoid rebuilding everything on every commit. This pattern uses path filters to conditionally trigger jobs based on which packages changed. :::

Progressive Deployment Pattern

Canary → Blue/Green → Full Rollout

jobs:
  deploy-canary:
    runs-on: ubuntu-latest
    environment:
      name: production-canary
      url: https://canary.example.com
    steps:
      - run: deploy-to-canary.sh
  
  smoke-test:
    needs: deploy-canary
    runs-on: ubuntu-latest
    steps:
      - run: smoke-test.sh https://canary.example.com
  
  deploy-production:
    needs: smoke-test
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - run: deploy-blue-green.sh
  
  monitor:
    needs: deploy-production
    runs-on: ubuntu-latest
    steps:
      - run: monitor-metrics.sh
      - run: auto-rollback-if-errors.sh

::: notes Progressive deployment reduces risk by rolling out changes incrementally. Canary deployments test with a small user subset, blue/green deployments enable instant rollback, and monitoring triggers automated rollback on errors. :::

Multi-Cloud Deployment Pattern

Deploy to AWS, Azure, GCP Simultaneously

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: docker build -t app:$
      - run: docker save app:$ > app.tar
      - uses: actions/upload-artifact@v4
        with:
          name: docker-image
          path: app.tar
  
  deploy-aws:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      id-token: write
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: $
      - run: deploy-to-ecs.sh
  
  deploy-azure:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v1
      - run: deploy-to-aks.sh
  
  deploy-gcp:
    needs: build
    runs-on: ubuntu-latest
    permissions:
      id-token: write
    steps:
      - uses: google-github-actions/auth@v1
        with:
          workload_identity_provider: $
      - run: deploy-to-gke.sh

::: notes Multi-cloud deployments require coordinating credentials, artifact distribution, and deployment procedures across providers. This pattern builds once, uploads the artifact, then deploys in parallel to multiple clouds. :::

Advanced Patterns and Best Practices

Composite Actions: Reusable Steps

Package Related Steps Together Usage:

# .github/actions/setup-node-app/action.yml
name: Setup Node.js Application
description: Install Node.js, restore cache, install dependencies

inputs:
  node-version:
    required: true
    description: Node.js version to use

runs:
  using: composite
  steps:
    - uses: actions/setup-node@v4
      with:
        node-version: $
        cache: 'npm'
    
    - shell: bash
      run: |
        npm ci
        npm run build
    
    - shell: bash
      run: |
        echo "::notice::App built successfully"

- uses: ./.github/actions/setup-node-app
  with:
    node-version: '20'

::: notes Composite actions bundle multiple steps into a single reusable unit. Use them for repetitive setup logic that appears across multiple workflows. :::

Job Concurrency Control

Prevent Concurrent Deployments Use Cases:

on: push: branches: [main]

concurrency: group: production-deploy cancel-in-progress: false

jobs: deploy: runs-on: ubuntu-latest steps: - run: deploy-to-production.sh


::: notes
Concurrency groups ensure that only one workflow run executes at a time. This prevents race conditions during deployment and resource contention during builds.
:::

---

## Environment Protection Rules

**Manual Approval for Production**
**Environment Settings (Repository Settings → Environments):**
- Required reviewers
- Wait timer (e.g., 5 minutes)
- Deployment branches (e.g., only `main`)
- Environment secrets
```yaml
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment:
      name: staging
      url: https://staging.example.com
    steps:
      - run: deploy.sh
  
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment:
      name: production
      url: https://example.com
    steps:
      - run: deploy.sh

::: notes GitHub Environments provide deployment gates. Configure required approvers so that production deployments need manual sign-off, wait timers for gradual rollout, and branch restrictions for security. :::

Artifact Sharing Between Jobs

Build Once, Deploy Many Times

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: npm run build
      - uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/
          retention-days: 7
  
  test-e2e:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist/
      - run: npm run test:e2e
  
  deploy:
    needs: [build, test-e2e]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
      - run: deploy.sh

::: notes Artifacts persist build outputs between jobs. This enables separation of concerns: build once, then test and deploy in parallel using the same artifact. Reduces build time and ensures consistency. :::

Matrix Build with Exclusions

Flexible Test Combinations

strategy:
  fail-fast: false
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
    node: [18, 20, 22]
    exclude:
      - os: macos-latest
        node: 18
      - os: windows-latest
        node: 18
    include:
      - os: ubuntu-latest
        node: 22
        experimental: true
        coverage: true

runs-on: $
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: $
  
  - run: npm test
  
  - if: matrix.coverage
    run: npm run coverage

::: notes Matrix exclusions remove specific combinations (e.g., older Node on macOS). Include adds extra attributes to specific combinations. This provides fine-grained control over test matrix explosion. :::

Caching Strategies

Speed Up Workflows with Smart Caching

jobs:
  build:
    steps:
      # Language-specific cache
      - uses: actions/setup-node@v4
        with:
          cache: 'npm'
      
      # Custom cache
      - uses: actions/cache@v4
        with:
          path: |
            ~/.cargo
            target/
          key: $-cargo-$
          restore-keys: |
            $-cargo-
      
      # Docker layer cache
      - uses: docker/build-push-action@v5
        with:
          cache-from: type=gha
          cache-to: type=gha,mode=max

::: notes Caching dramatically reduces workflow execution time. Language-specific caches are built into setup actions. Custom caches handle tools, build artifacts, and dependencies. Docker layer caching reuses unchanged layers. :::

GitHub Packages and Container Registry

GitHub Container Registry (GHCR)

Native Docker Image Hosting Benefits:

::: notes GHCR provides a first-class Docker registry integrated with GitHub authentication and permissions. Images are scoped to repositories or users, and public images are free with unlimited storage. :::

GitHub Packages: Language Package Hosting

Publish npm, Maven, NuGet, RubyGems, and More Supported Ecosystems:

::: notes GitHub Packages hosts language-specific packages alongside your code. This eliminates the need for separate Artifactory, Nexus, or package registry services for private packages. :::

Organization-Level Patterns

Organization Secrets and Variables

Centralized Configuration Management Scope Hierarchy:

  1. Organization - All repos or selected repos
  2. Repository - Single repository
  3. Environment - Specific deployment environment ```yaml jobs: deploy: runs-on: ubuntu-latest steps:

    • name: Deploy env: # Organization-level secrets AWS_ROLE: $ SLACK_WEBHOOK: $

      # Organization-level variables CDN_URL: $ API_ENDPOINT: $ run: deploy.sh ```

::: notes Organization secrets and variables eliminate duplication. Set AWS roles, Slack webhooks, or API endpoints once at the org level, then all repositories inherit them. :::

Required Workflows

Enforce Compliance Across Repositories Organization administrators can mandate workflows that run on every repository: Use Cases:

on: push: pull_request:

jobs: scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4

  - name: Run security scan
    uses: github/super-linter@v5
  
  - name: Dependency scan
    uses: github/dependency-review-action@v3
  
  - name: Secret scan
    uses: trufflesecurity/trufflehog@main ```

::: notes Required workflows run on all repositories in the organization, even if the repository doesn’t have that workflow file. This ensures compliance with security, legal, or quality requirements. :::

Starter Workflows

Accelerate Repository Onboarding Organization .github repository: When creating a new workflow, users see organization templates as suggestions.

# .github/workflows/ci.yml in .github repository
name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make build
      - run: make test

.github/
├── workflow-templates/
│   ├── ci.yml
│   ├── ci.properties.json  # Metadata
│   └── icons/
│       └── ci.svg

::: notes Starter workflows appear in the “New workflow” UI for repositories in your organization. This guides developers toward approved patterns and reduces copy-paste errors. :::

Observability and Monitoring

Workflow Status Badges

Visibility into CI/CD Health Badge Features:

::: notes Status badges provide at-a-glance CI/CD health. Displayed in README files, they immediately show whether builds are passing and tests are green. :::

Workflow Notifications

Multi-Channel Alerting

jobs:
  notify-failure:
    runs-on: ubuntu-latest
    if: failure()
    needs: [build, test, deploy]
    steps:
      # Slack notification
      - uses: slackapi/slack-github-action@v1
        with:
          webhook-url: $
          payload: |
            {
              "text": "Deployment failed: $"
            }
      
      # Email notification
      - uses: dawidd6/action-send-mail@v3
        with:
          server_address: smtp.gmail.com
          server_port: 465
          username: $
          password: $
          subject: "Build failure: $"
          body: "Workflow $ failed"
      
      # PagerDuty alert
      - uses: brunomacabeusbr/pagerduty-action@v2
        with:
          pagerduty-integration-key: $

::: notes Proactive notifications ensure teams know immediately when workflows fail. Route critical failures to PagerDuty, informational messages to Slack, and summaries to email. :::

Metrics and Analytics

Workflow Performance Insights GitHub provides built-in analytics:

::: notes GitHub’s workflow insights help you optimize CI/CD performance. Track which jobs take longest, identify flaky tests, and monitor runner usage to control costs. :::

Self-Hosted Runners

When to Use Self-Hosted Runners

Cost Comparison:

::: notes GitHub-hosted runners are convenient and zero-maintenance. Self-hosted runners make sense for specialized hardware, internal network access, or very high-volume builds where cost becomes a factor. :::

Self-Hosted Runner Setup

Runner Features:

Download runner package

curl -o actions-runner-linux-x64-2.311.0.tar.gz -L
https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz

Extract and configure

tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz ./config.sh –url https://github.com/org/repo –token

Run as service

sudo ./svc.sh install sudo ./svc.sh start


::: notes
Self-hosted runners register with GitHub and poll for jobs. Use runner labels to target specific capabilities. Ephemeral runners enhance security by ensuring clean state for each job.
:::

---

# Cost Optimization


---

## Optimizing Workflow Costs

### Free Tier Limits (Public Repos)
- **Unlimited** minutes on Linux GitHub-hosted
- 20 concurrent jobs
### Private Repo Pricing
- 2,000 minutes/month free
- Then $0.008/minute (Linux)
::: columns
:::: column
### Reduce Execution Time
- Cache dependencies
- Parallelize jobs
- Use matrix builds efficiently
- Skip unnecessary jobs
- Optimize build steps
::::
:::: column
### Reduce Compute Usage
- Use smaller runners when possible
- Self-host for high volume
- Schedule non-critical jobs off-peak
- Cancel redundant runs
- Use `concurrency` to queue
::::
:::

::: notes
Workflow costs add up in large organizations. Optimize by reducing job duration through caching, avoiding redundant builds through concurrency controls, and self-hosting high-volume workloads.
:::

---

## Example: Conditional Job Execution

```yaml
jobs:
  # Only run expensive E2E tests on main and PRs to main
  e2e-test:
    if: github.ref == 'refs/heads/main' || github.base_ref == 'main'
    runs-on: ubuntu-latest
    steps:
      - run: npm run test:e2e
  
  # Only run security scans on schedule and releases
  security-scan:
    if: github.event_name == 'schedule' || startsWith(github.ref, 'refs/tags/')
    runs-on: ubuntu-latest
    steps:
      - run: npm audit
  
  # Cancel redundant workflow runs
  cancel-redundant:
    runs-on: ubuntu-latest
    steps:
      - uses: styfle/cancel-workflow-action@v0.12
        with:
          access_token: $

::: notes Conditional execution prevents wasteful builds. Run expensive E2E tests only on important branches, security scans on schedule, and cancel superseded runs when pushing multiple commits rapidly. :::

Implementation Roadmap

Phase 1: Foundation (Weeks 1-4)

::: columns :::: column

Week 1-2: Core Setup

::: notes Start with the fundamentals. Establish the central workflow library, configure organization-level resources, and implement security baseline before rolling out to teams. :::

Phase 2: Automation (Weeks 5-8)

Build Reusable Workflow Library:

::: notes Create a library of organization-standard workflows that teams can consume. Migrate high-impact repositories first to establish patterns, then roll out broadly. :::

Phase 3: Scale and Optimize (Weeks 9-12)

Enablement:

::: notes At scale, observability and optimization become critical. Monitor workflow health, optimize costs, and invest in enablement so teams can self-serve effectively. :::

Best Practices Summary

Security Best Practices

✅ DO:

::: notes Security is non-negotiable. Follow these practices to protect your supply chain, credentials, and infrastructure from compromise. :::

Workflow Design Best Practices

✅ DO:

::: notes Well-designed workflows are fast, reliable, and maintainable. Apply software engineering principles: DRY, separation of concerns, and defensive programming. :::

Organizational Best Practices

✅ DO:

::: notes Organization-level governance scales automation while maintaining consistency and compliance. Centralize configuration, standardize patterns, and provide guard rails. :::

Key Takeaways

The GitHub Ecosystem Advantage

Integrated Platform Benefits:

  1. Single Source of Truth - Code, CI/CD, packages, issues unified
  2. Zero External Dependencies - No Jenkins, Artifactory, Jira setup
  3. Built-In Security - Secret scanning, Dependabot, code scanning
  4. Native Collaboration - PR reviews, code comments, status checks
  5. Cost Effective - Free for open source, predictable pricing for private
  6. Ecosystem Network Effects - 50M+ developers, 20K+ marketplace actions

::: notes GitHub’s integration eliminates the friction of connecting disparate tools. The ecosystem’s maturity means solutions exist for nearly every automation need. :::

Success Metrics

Measure What Matters: Additional KPIs:

::: notes Track DORA metrics to measure DevOps transformation. GitHub Actions enables the automation that drives improvements in deployment frequency, lead time, and reliability. :::

Getting Started: First Steps

Week 1 Action Items:

  1. Audit Current State - Inventory existing CI/CD tools and workflows
  2. Define Standards - Document organization patterns and policies
  3. Pilot Project - Migrate one high-value repository
  4. Build Library - Create 2-3 reusable workflows
  5. Enable Security - Configure SHA pinning and OIDC
  6. Training Plan - Schedule enablement sessions Quick Win: Convert simple build workflow to reusable pattern

::: notes Start small but strategic. Pick a repository that will benefit immediately, establish the pattern, then scale. Early wins build momentum. :::

Resources and References

Official Documentation

GitHub Docs:

::: notes GitHub’s documentation is comprehensive and well-maintained. The learning paths provide hands-on practice with workflows, security, and advanced patterns. :::

Community and Tools

Marketplace:

::: notes The GitHub community has built extensive tooling around Actions. Leverage marketplace actions for common tasks, security tools for hardening, and monitoring for visibility. :::

Project References

Featured Projects from This Ecosystem:

::: notes This presentation’s own repository demonstrates many of the patterns discussed: content automation, presentation generation, scheduled publishing, and comprehensive CI/CD. :::

Questions and Discussion

Discussion Topics

Popular Questions:

  1. How do we migrate from Jenkins/CircleCI to GitHub Actions?
  2. What’s the ROI calculation for self-hosted runners?
  3. How do we enforce security policies across 100+ repositories?
  4. Can we use GitHub Actions for non-CI/CD automation?
  5. How does GitHub Actions compare to GitLab CI or Azure DevOps? Open Discussion: What challenges is your organization facing with CI/CD automation?

::: notes Every organization’s context is unique. The patterns and tools are flexible—adapt them to your specific requirements, compliance needs, and scale. :::

Thank You

Robert Allen GitHub: @zircote Website: zircote.com Explore the Ecosystem:

::: notes Thank you for your time and attention. I hope this overview of the GitHub ecosystem provides a foundation for transforming your organization’s DevOps practices. Feel free to reach out with questions or to discuss implementation strategies. :::