GitHub Actions - Reusable Workflows Library
March 2, 2022 ยท View on GitHub
GitHub Actions reusable workflows library to be reused between GitHub repos.
See Documentation for how to call these workflows directly from your own GitHub Actions workflow.
Examples
In your GitHub repo, import these workflows by adding small yaml files to the .github/workflows/ directory.
Scan for Secrets and Security issues
Alerts appear under Security -> Code scanning alerts.
Create .github/workflows/semgrep.yaml:
on: [push]
jobs:
semgrep:
uses: buluma/GitHub-Actions/.github/workflows/semgrep.yaml@master
Analyze your Terraform code security & best practices
Alerts appear under Security -> Code scanning alerts.
Create .github/workflows/tfsec.yaml:
on: [push]
jobs:
tfsec:
uses: buluma/GitHub-Actions/.github/workflows/tfsec.yaml@master
Docker Build and push to DockerHub
Create .github/workflows/docker_build.yaml:
on: [push]
jobs:
docker_build:
uses: buluma/GitHub-Actions/.github/workflows/docker_build.yaml@master
with:
repo: harisekhon/bash-tools # DockerHub user/repo
tags: latest ubuntu # builds, tags as harisekhon/bash-tools:latest and harisekhon/bash-tools:ubuntu and pushes to DockerHub
context: devops-bash-tools-ubuntu # path to dir containing the source and Dockerfile
#max-cache: true # if you need multi-stage caching (uses a separate cache image)
secrets:
DOCKERHUB_USER: ${{ secrets.DOCKERHUB_USER }}
DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }}
Docker Build and push to AWS ECR
Create .github/workflows/docker_build_aws_ecr.yaml:
on: [push]
jobs:
docker_build:
uses: buluma/GitHub-Actions/.github/workflows/docker_build_aws_ecr.yaml@master
with:
repo: MY_ECR_REPO # without the 'xxx.dkr.ecr.<region>.amazonaws.com' prefix
secrets:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_DEFAULT_REGION: ${{ secrets.AWS_DEFAULT_REGION }}
This auto-adds tags:
latest- Git branch or tag
- Git SHA
- Epoch in seconds
- Date
- Date & Timestamp
Makes heavy use of all several possible caches including branch/tag specific caches to speed up builds / re-builds and avoid cache invalidation between environments.
Supports multi-stage build caching using GHCR for intermediate layer caching since AWS ECR doesn't support this at time of writing, simply by adding:
with:
max-cache: true
Check for Broken URL Links
Create .github/workflows/url_links.yaml:
on: [push]
jobs:
url_links:
uses: buluma/GitHub-Actions/.github/workflows/url_links.yaml@master
with:
# custom ignore inaccessible / internal / partially constructed links or those containing variables
# this is a multi-line string, one URL or partial ERE regex match per line
url_links_ignored: |
https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2Fv
# ignore URLs without dots as these are usually internal inaccessible local addresses such as http://krb5server rather than public accessible links
#ignore_urls_without_dots: 'true' # any value enables this
Auto-Merge Production hotfixes back to Staging
Merges via a Pull Request for full auditing.
Create .github/workflows/merge_production_to_staging.yaml:
on: [push]
jobs:
merge:
if: github.ref_name == 'production'
name: Merge Production Branch to Staging Branch (hotfix backports)
uses: buluma/GitHub-Actions/.github/workflows/merge-branch.yaml@master
with:
head: production # from - optional - if omitted defaults to the trigger branch, which is always 'production' due to the if condition above
base: staging # to
Permissions
These workflows are locked down to the minimal required permissions as per the best practice principal of least privilege, usually just contents: read, but some require extra permissions to create Pull Requests or write Security Alerts to the GitHub Security tab.
If you've locked down your GitHub Organizations permissions to default to contents: read (which I recommend), then you may want to copy the permissions key out of the workflow to your calling workflow to grant them the needed permissions.
Security Alerts
permissions:
actions: read
contents: read
security-events: write
These 3 permissions are needed for workflows that report to GitHub Security tab, including:
Linting Auto-fixers
For workflows that lint-and-fix code, such as terraform-fmt-write.yaml, you'll need to grant:
permissions:
contents: write # if called by on: push
pull-requests: write # if called by on: pull_request
Creating or Commenting on Pull Requests
For workflows that create or comment on PRs, such as tfsec-pr-commenter.yaml you'll need to grant:
permissions:
contents: read
pull-requests: write
Merging Pull Requests
For workflows that merge PRs, such as merge-branch.yaml you'll need to grant:
permissions:
contents: write
pull-requests: write