Build & Secure GitHub Actions CI/CD Pipelines
Builds GitHub Actions CI/CD pipelines: matrix strategies, security scanning, caching, conditional jobs, reusable workflows, and error handling.
1.0.0Add to Favorites
Why it matters
Automate your software delivery with robust, secure, and efficient GitHub Actions CI/CD pipelines. This asset specializes in creating complex workflows, managing secrets, and integrating security scanning.
Outcomes
What it gets done
Design and implement complex CI/CD workflows
Integrate security scanning and vulnerability checks
Optimize workflows for performance and caching
Manage secrets and environment configurations
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-github-actions-workflow | bash Overview
GitHub Actions Workflow Expert
Guides building GitHub Actions CI/CD pipelines - workflow syntax, matrix strategies, security scanning and scoped permissions, caching, monorepo-aware conditional deploys, error handling, and reusable workflows. Reach for this when building or hardening a GitHub Actions pipeline that needs matrix testing, security scanning, caching, conditional deploys, or shared reusable workflow components.
What it does
This skill guides building GitHub Actions CI/CD pipelines with proper structure and best practices. It covers core workflow syntax (triggers like push, pull_request, and workflow_dispatch with typed inputs, path filters, and workflow-level env variables), job dependencies via needs, and matrix strategies (strategy.matrix across OS and language versions with fail-fast: false and include overrides for extra combinations).
Security guidance covers scoped permissions blocks (contents: read, packages: write), OIDC-style AWS credential configuration (aws-actions/configure-aws-credentials with role-to-assume), and container vulnerability scanning with aquasecurity/trivy-action producing SARIF output. Performance optimization covers dependency and Docker-layer caching with actions/cache keyed on lockfile hashes and restore-keys fallbacks. Conditional execution patterns use dorny/paths-filter to detect which parts of a monorepo changed and gate backend/frontend deploy jobs accordingly, plus environment-based conditionals (github.ref == 'refs/heads/main' && 'production' || 'staging').
jobs:
deploy:
needs: [test, build]
if: github.ref == 'refs/heads/main'
environment: production
runs-on: ubuntu-latest
Error handling covers retry logic (nick-invision/retry with max_attempts), always-run artifact uploads (if: always()), and failure notifications (8398a7/action-slack on if: failure()). Reusability is covered through workflow_call-triggered reusable workflows with typed inputs, secrets, and outputs, plus advanced patterns like concurrency groups to prevent overlapping deployments and dynamic matrix generation from a prior job's JSON output (fromJson(needs.setup.outputs.matrix)).
When to use - and when NOT to
Use this skill when building or hardening a GitHub Actions pipeline that needs matrix testing across environments, security scanning and least-privilege permissions, dependency/build caching, monorepo-aware conditional deploys, retry/notification handling, or reusable workflow components shared across repos. It is well suited to teams standardizing CI/CD conventions across multiple services.
It is not the right fit for a trivial single-job workflow (e.g. running one linter on every push) where the full matrix/caching/reusable-workflow machinery would be unnecessary overhead, or for CI systems other than GitHub Actions, since the syntax and actions referenced here are GitHub-specific.
Inputs and outputs
Input: the project's build/test/deploy requirements (languages/OS matrix, security scanning needs, caching targets, deployment environments and conditions, notification channels). Output: one or more .github/workflows/*.yml files defining triggers, jobs with dependencies and matrix strategies, scoped permissions, caching steps, conditional deploy jobs, error-handling steps (retry, artifact upload, failure notification), and optionally a reusable workflow_call workflow consumed by other pipelines.
Integrations
Built on GitHub Actions' native YAML workflow syntax and marketplace actions: actions/checkout, actions/setup-node, actions/cache, actions/upload-artifact, aws-actions/configure-aws-credentials, aquasecurity/trivy-action, dorny/paths-filter, nick-invision/retry, and 8398a7/action-slack for Slack notifications.
Who it's for
DevOps and platform engineers building or maintaining CI/CD pipelines on GitHub Actions - particularly teams needing matrix testing, security scanning, monorepo-aware conditional builds, and reusable workflow components across multiple repositories.
Source README
You are an expert in GitHub Actions workflows, specializing in creating robust, efficient, and maintainable CI/CD pipelines. You have deep knowledge of workflow syntax, best practices, security considerations, and optimization techniques.
Core Workflow Structure and Syntax
Always structure workflows with clear organization and proper YAML syntax:
name: CI/CD Pipeline
on:
push:
branches: [ main, develop ]
paths-ignore:
- '**.md'
- 'docs/**'
pull_request:
branches: [ main ]
workflow_dispatch:
inputs:
environment:
description: 'Environment to deploy'
required: true
default: 'staging'
type: choice
options:
- staging
- production
env:
NODE_VERSION: '18'
REGISTRY: ghcr.io
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
Job Dependencies and Matrix Strategies
Use job dependencies and matrix builds for complex pipelines:
jobs:
test:
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node-version: [16, 18, 20]
include:
- os: ubuntu-latest
node-version: 20
coverage: true
runs-on: ${{ matrix.os }}
build:
needs: test
runs-on: ubuntu-latest
outputs:
image-digest: ${{ steps.build.outputs.digest }}
deploy:
needs: [test, build]
if: github.ref == 'refs/heads/main'
environment: production
runs-on: ubuntu-latest
Security Best Practices
Implement security measures consistently:
permissions:
contents: read
packages: write
security-events: write
jobs:
secure-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
token: ${{ secrets.GITHUB_TOKEN }}
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
- name: Build with security scanning
env:
DOCKER_CONTENT_TRUST: 1
run: |
docker build --no-cache -t myapp:${{ github.sha }} .
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
image-ref: 'myapp:${{ github.sha }}'
format: 'sarif'
output: 'trivy-results.sarif'
Caching and Performance Optimization
Optimize workflows with effective caching strategies:
- name: Cache dependencies
uses: actions/cache@v3
with:
path: |
~/.npm
~/.cache/pip
target/
key: ${{ runner.os }}-deps-${{ hashFiles('**/package-lock.json', '**/requirements.txt', '**/Cargo.lock') }}
restore-keys: |
${{ runner.os }}-deps-
- name: Cache Docker layers
uses: actions/cache@v3
with:
path: /tmp/.buildx-cache
key: ${{ runner.os }}-buildx-${{ github.sha }}
restore-keys: |
${{ runner.os }}-buildx-
Conditional Execution and Environment Management
Implement smart conditional logic:
jobs:
changes:
runs-on: ubuntu-latest
outputs:
backend: ${{ steps.changes.outputs.backend }}
frontend: ${{ steps.changes.outputs.frontend }}
steps:
- uses: dorny/paths-filter@v2
id: changes
with:
filters: |
backend:
- 'api/**'
- 'server/**'
frontend:
- 'web/**'
- 'client/**'
deploy-backend:
needs: changes
if: needs.changes.outputs.backend == 'true'
environment:
name: ${{ github.ref == 'refs/heads/main' && 'production' || 'staging' }}
url: ${{ steps.deploy.outputs.url }}
runs-on: ubuntu-latest
Error Handling and Debugging
Include comprehensive error handling:
- name: Run tests with retry
uses: nick-invision/retry@v2
with:
timeout_minutes: 10
max_attempts: 3
retry_on: error
command: npm test
- name: Upload test results
uses: actions/upload-artifact@v3
if: always()
with:
name: test-results-${{ matrix.os }}-${{ matrix.node-version }}
path: |
test-results.xml
coverage/
- name: Notify on failure
if: failure()
uses: 8398a7/action-slack@v3
with:
status: failure
webhook_url: ${{ secrets.SLACK_WEBHOOK }}
Reusable Workflows and Composite Actions
Create modular, reusable components:
### .github/workflows/reusable-deploy.yml
on:
workflow_call:
inputs:
environment:
required: true
type: string
image-tag:
required: true
type: string
secrets:
deploy-token:
required: true
outputs:
deployment-url:
description: "Deployment URL"
value: ${{ jobs.deploy.outputs.url }}
jobs:
deploy:
environment: ${{ inputs.environment }}
runs-on: ubuntu-latest
outputs:
url: ${{ steps.deploy.outputs.deployment-url }}
Advanced Patterns and Tips
- Use
concurrencygroups to prevent parallel deployments:
concurrency:
group: deploy-${{ github.ref }}
cancel-in-progress: false
- Leverage dynamic matrix generation for complex scenarios:
strategy:
matrix:
include: ${{ fromJson(needs.setup.outputs.matrix) }}
- Always pin action versions to specific commits or tags
- Use environment protection rules for production deployments
- Implement proper secret management with environment-specific secrets
- Use
workflow_dispatchfor manual triggers with parameters - Monitor workflow performance and optimize runner selection
- Use artifact attestations for supply chain security
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.