Skip to content

button-inc/gh-actions

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

55 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Github Actions Templates

This project contains all Github Actions templates. To make use of the repository, fork this repository and modify the env and trigger sections of each template to meet the needs of your application or repository.

How to Use

  1. To get started, copy one of the workflow templates to your own repository under .github/workflows/<workflow_name>.

  2. Create any referenced secrets in settings > repository secrets.

  3. Push a change to trigger the workflow. The workflow will call the button-inc/button-shared-gh-actions repository.

When a workflow is called, it is imported into the callers context, and executes as if all the logic is running locally within the repository.

Workflow Templates

Docker Build Push

name: build-push-docker
on:
  workflow_dispatch:
  push:
jobs:
  build-push:
    uses: button-inc/gh-actions/.github/workflows/build-push-docker.yml@develop
    with:
      image-registry: docker.io
      image: gregnrobinson/bcgov-nginx-demo
      workdir: ./demo/nginx
    secrets:
      image-registry-user: ${{ secrets.image-registry-user }}
      image-registry-password: ${{ secrets.image-registry-password }}

Back to top

Trivy Scan

name: trivy-scan
on:
  workflow_dispatch:
  push:
jobs:
  trivy-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-trivy.yml@develop

Back to top

SonarCloud Scan

name: sonarcloud-scan
on:
  workflow_dispatch:
  push:
jobs:
  sonarcloud-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-sonarcloud.yml@develop
    secrets:
      github-token: ${{ secrets.GITHUB_TOKEN }}
      sonar-token: ${{ secrets.SONAR_TOKEN}}

Back to top

Husky Scan

name: husky-scan
on:
  workflow_dispatch:
  push:
jobs:   
  husky-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-husky.yml@develop
    with:
      working-directory: ./app
      node-version: '18' 

Back to top

Gitleaks Scan

gitleaks.toml in the root dir allows you write your own secret detection rules, here for more information.

name: gitleaks-scan
on:
  workflow_dispatch:
  push:
jobs:   
  gitleaks-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-gitleaks.yml@develop
  secrets:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    gitleaks-license: ${{ secrets.GITLEAKS_LICENSE}}

Back to top

OWASP ZAP Scan

It builds the app and allows ZAP scans against localhost.

name: zap-scan
on:
  workflow_dispatch:
  push:
jobs:   
  zap-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-owasp-zap.yml@develop
    with:
      target-url: 'http://localhost:3000'

Back to top

Playwright Tests

name: playwright-tests
on:
  workflow_dispatch:
  push:
jobs:
  playwright-tests:
    uses: button-inc/gh-actions/.github/workflows/test-code-playwright.yml@develop

Back to top

Workflow Triggers

# Set triggers to tell the workflow when it should run...
on:
  push:
    branches:
    - main
    paths-ignore:
    - 'README.md'
    - '.pre-commit-config.yaml'
    - './github/workflows/pre-commit-check.yaml'
  workflow_dispatch:

# A schedule can be defined using cron format.
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

    # Layout of cron schedule.  'minute hour day(month) month day(week)'
    # Schedule option to review code at rest for possible net-new threats/CVE's
    # List of Cron Schedule Examples can be found at https://crontab.guru/examples.html
    # Top of Every Hour ie: 17:00:00. '0 * * * *'
    # Midnight Daily ie: 00:00:00. '0 0 * * *'
    # 12AM UTC --> 8PM EST. '0 0 * * *'
    # Midnight Friday. '0 0 * * FRI'
    # Once a week at midnight Sunday. '0 0 * * 0'
    # First day of the month at midnight. '0 0 1 * *'
    # Every Quarter. '0 0 1 */3 *'
    # Every 6 months. '0 0 1 */6 *'
    # Every Year. '0 0 1 1 *'
    #- cron: '0 0 * * *'
  ...

Back to top

Secrets Management

The following repository secrets are required depending on which template is being used. Learn more.

Secret Name Description
image-registry-user Registry username. Used for interacting with private image repositories.
image-registry-password Registry password. Used for interacting with private image repositories.
gitleaks-license If you are scanning repos that belong to a GitHub personal account, then no license key is required. If you are scanning repos that belong to a GitHub organization account, then you'll have to obtain a free license here.
sonar_token Used when using the Sonar scanning templates.

Back to top

Specifying Action Versions and Branches

In your workflows, you can specify not only the version of a reusable action, but also the branch from which to pull the action. This is done by appending @<branch> or @<version> to the end of the action reference in your workflow file.

For instance, if you want to use the latest version of the playwright tests action from the develop branch, you would reference it like this:

uses: button-inc/gh-actions/.github/workflows/test-code-playwright.yml@develop

This will always use the most recent version of the action from the develop branch. This can be useful when you want to test the latest changes that are not yet released.

However, there might be situations where you want to use a specific version of an action. In such cases, you can specify the version number instead of the branch:

uses: button-inc/gh-actions/.github/workflows/test-code-playwright.yml@v0.0.1

This ensures that your workflow uses a specific, known version of the action, providing stability and predictability. It's particularly useful when you want to ensure that your workflow doesn't break due to changes in the latest version.

Back to top

Keeping Your Actions Up-to-Date with Dependabot

Dependabot is a tool provided by GitHub that can automatically check for new versions of dependencies, including reusable GitHub Actions. You can configure Dependabot to periodically check for new versions of the actions used in your workflows, and open a pull request to update the version whenever a new one is available.

To set up Dependabot for your GitHub Actions, you'll need to add a new configuration file at .github/dependabot.yml in your repository. Here's an example configuration that checks for updates to GitHub Actions weekly:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

With this configuration, Dependabot will check for new versions of all GitHub Actions used in your repository every week. If a new version is found, Dependabot will open a pull request with the necessary changes to update to the new version.

Example of the pull request: image

For more information on configuring Dependabot for GitHub Actions, see the official documentation.

Back to top

Specifying the Package Manager

The scan-code-owasp-zap.yml and test-code-playwright.yml actions have an optional input named package-manager. This allows you to specify the package manager you'd like to use for the workflow. If no input is given, it defaults to npm. Currently, it supports npm, yarn, and pnpm.

Here's an example of how you can specify yarn as the package manager for the scan-code-owasp-zap.yml action:

name: zap-scan
on:
  workflow_dispatch:
  push:
jobs:   
  zap-scan:
    uses: button-inc/gh-actions/.github/workflows/scan-code-owasp-zap.yml@develop
    with:
      package-manager: 'yarn'

In this example, the scan-code-owasp-zap.yml action will use yarn to manage packages instead of the default npm. This can be particularly useful if your project uses yarn and has a yarn.lock file.

Remember to ensure that your project is correctly configured to use the specified package manager. For instance, if you specify yarn, your project should have a yarn.lock file.

Back to top

Reference

Workflow Syntax

Workflow Triggers

Reusing workflows

Dependabot auto-update actions

Back to top