Skip to content

GitHub Action workflows that can be shared by multiple repositories

License

Notifications You must be signed in to change notification settings

broadinstitute/shared-workflows

shared-workflows

GitHub Action workflows that can be shared by multiple repositories

Provided Workflows

Default parameters

All workflows in this repository provide at least the following default parameters that can be passed with with: from calling repositories:

  • jobs_run_on: The runner group on which jobs will run. Default: ubuntu-latest
  • timeout_minutes: The maximum time (in minutes) for a job to run. Default: 5
  • working_directory: The working directory where all jobs should be executed. Default: .

adr-check-toc.yaml

This workflow will run the adr generate toc command using adr to generate the Table of Contents for the ADRs in the repository. The workflow assumes the output goes to the README.md in the same directory as the ADRs. This check makes sure PRs haven't forgotten to run this command as part of their commits.

ansible-lint.yaml

This workflow will setup Python (3.11) and lint the repository using both yamllint and ansible-lint. Poetry is used to install the Python dependencies. Both yamllint and ansible-lint are expected to be installed by the Poetry configuration in the repository using this workflow.

ansible-lint Inputs

  • additional_packages: String of additional packages that should be installed. Default: ``
  • python_version: The version of Python to use. Default: 3.11

conventional-commit.yaml

This workflow will run thecommitlint By default it only checks that PR titles follow Conventional Commits. In addition the 'subject-case' and 'body-max-line-length' checks are disabled.

  • validate_pr_title: Validate PR title. Default: true
  • validate_current_commit: Validate current commit (last commit). Default: false
  • validate_pr_commits: Validate PR commits. Default: false

local-checks.yaml

These are local Actions that run for this repository. This workflow is not visible or usable outside of this repository.

markdownlint.yaml

This workflow will run the DavidAnson/markdownlint-cli2-action action to lint markdown files.

markdownlint Inputs

  • config_file: The configuration file to use. Default: .markdownlint-cli2.yaml
  • fix: If set to true, fix any issues found. Default: false
  • globs: The glob to use to find all markdown files. Default: **/*.md
  • separator: The character used to separate globs. Default: ,

pre-commit.yaml

This workflow runs the pre-commmit action with minimal options for configuration.

puppet-build.yaml

This workflow will setup Puppet using ruby/setup-ruby (Ruby version 3.2). The linting and dependency installations will all happen using PDK. The Puppet module will be built with PDK and then installed using puppet module install to test that the build and install process works as expected.

puppet-build Inputs

  • puppet_package_name: The name of the Puppet module the repo will create. Default: ``
  • puppet_version: The version of Puppet to use in PDK. Default: 7
  • ruby_version: The version of Ruby to use. Default: 3.2

puppet-forge-deploy.yaml

This workflow will setup Puppet using ruby/setup-ruby. The linting and dependency installations will all happen using PDK. The Puppet module will be built with PDK and then pushed to the Puppet Forge.

puppet-forge-deploy Inputs

  • puppet_version: The version of Puppet to use in PDK. Default: 7
  • ruby_version: The version of Ruby to use. Default: 3.2

puppet-forge-deploy Secrets

  • forge_token: The Puppet Forge token to use when deploying the module.

puppet-lint.yaml

This workflow will setup Puppet using ruby/setup-ruby (Ruby version 3.2). The linting and dependency installations will all happen using PDK.

puppet-linting Inputs

  • puppet_version: The version of Puppet to use in PDK. Default: 7
  • ruby_version: The version of Ruby to use. Default: 3.2

puppet-unit-test.yaml

This workflow will setup Puppet using ruby/setup-ruby. The testing will happen on a matrix of Ruby and Puppet versions. The dependency installation and unit tests will all happen using PDK.

puppet-unit-test Inputs

  • puppet_versions: The versions of Puppet to use in the unit tests, passed as a string in JSON format with versions as the key. Default: '{ "versions": [ "7", "8" ] }'
    • Note: Make sure to enclose the JSON string in single quotes!!
  • ruby_versions: The versions of Ruby to use in the unit tests, passed as a string in JSON format with versions as the key. Default: '{ "versions": [ "3.1", "3.2" ] }'
    • Note: Make sure to enclose the JSON string in single quotes!!

python-deploy-to-pypi.yaml

This workflow will setup Python (3.11) and do a build and deploy of the Python package to PyPi using Poetry.

python-deploy-to-pypi Inputs

  • additional_packages: String of additional packages that should be installed. Default: ``
  • poetry_install_options: Extra options to pass to Poetry when doing an install. Default: --no-root
  • python_version: The version of Python to use. Default: 3.11

python-deploy-to-pypi Secrets

  • pypi_token: The PyPi token to use to deploy. This secret is required for this workflow to push to PyPi

python-lint.yaml

This workflow will setup Python (3.11) and lint the repository. Poetry is used to install any Python dependencies. By default the linters run are yamllint, and pylama. As of August 2023, pylama has been deprecated, so you can run Ruff as the Python linter by setting the use_ruff input to true.

python-lint Inputs

  • additional_packages: String of additional packages that should be installed. Default: ``
  • poetry_install_options: Extra options to pass to Poetry when doing an install. Default: --no-root
  • python_version: The version of Python to use. Default: 3.11
  • ruff_version: The version of Ruff to run. Default: 0.1.0
  • use_pylama: If true, use pylama to lint the repository. Default: true
  • use_ruff: If true, use Ruff to lint the repository. Default: false

python-make-ci.yaml

This workflow will setup Python (3.12) and run make ci on the repository. Poetry is used to install any Python dependencies. It is the responsibility of the repository owner to correctly setup a Makefile to correctly do all the CI tasks for their repository. The prettier application as well as Node 22.x are also available to this workflow.

python-make-ci Inputs

There are no additional inputs for this workflow. Additionally, the jobs_run_on input is not available for this workflow as the job is forced to use ubuntu-latest for the base image.

python-test-deploy-to-pypi.yaml

This workflow will setup Python (3.11) and do a build and deploy of the Python package to Test PyPi using Poetry.

python-test-deploy-to-pypi Inputs

  • additional_packages: String of additional packages that should be installed. Default: ``
  • poetry_install_options: Extra options to pass to Poetry when doing an install. Default: --no-root
  • python_version: The version of Python to use. Default: 3.11

python-test-deploy-to-pypi Secrets

  • pypi_test_token: The PyPi token to use to deploy. This secret is required for this workflow to push to Test PyPi

python-unit-test.yaml

This workflow will setup a matrix of Python versions and run the unit tests for the repository using green. Poetry is used to install any Python dependencies.

python-unit-test Inputs

  • additional_packages: String of additional packages that should be installed. Default: ``
  • poetry_install_options: Extra options to pass to Poetry when doing an install. Default: --no-root
  • python_package_name: The name of the PyPi package the repo will create. Default: ``
  • python_versions: The versions of Python to use in the unit tests, passed as a string in JSON format with versions as the key. Default: '{ "versions": [ "3.7", "3.8", "3.9", "3.10", "3.11" ] }'
    • Note: Make sure to enclose the JSON string in single quotes!!
  • run_coverage: Boolean to determine whether coverage should be run or not. Default: true
  • test_runner: The runner used to run all the unit tests. Default: green
  • test_targets: A list of directories to target for testing. Runners should autodetect if left blank. Default: ``

terraform-docs.yaml

This workflow will setup and run terraform-docs to generate the Terraform documentation and store it in the README.md.

terraform-docs Inputs

  • config_file: The path to the configuration file. Default: .terraform-docs.yml
  • git_push: If set to true, push the changes to the repository. Default: false
  • output_file: The path to the output file. Default: README.md
  • output_method: The method to use for output. Default: inject
  • terragrunt_directory: The environment directory from which Terragrunt should run. Default: prod
  • use_terragrunt: If set to true, use Terragrunt instead of Terraform. Default: false

terraform-lint.yaml

This workflow will setup and run tflint as well as the pre-commit/action Action to run pre-commit.

terraform-lint Inputs

  • tflint_config_path: The relative path to the TFlint configuration file. Default: .tflint.hcl

terraform-static-analyze.yaml

This workflow will setup and run some static analysis tools for Terraform. The only test that runs by default is tfsec using the aquasecurity/tfsec-pr-commenter-action Action. You can optionally run Checkov (using the bridgecrewio/checkov-action Action) and Trivy (using the aquasecurity/trivy-action Action).

terraform-static-analyze Inputs

  • run_checkov: If set to true, run checkov tests. Default: false
  • run_tfsec: If set to true, run tfsec tests. Default: true
  • run_trivy: If set to true, run Trivy tests. Default: false
  • trivy_skip_files: A comma-separated list of files Trivy should ignore. Default: ``

terraform-static-analyze Secrets

  • wf_github_token: Description: The GitHub token to use when running tfsec so that it can post comments to the PR. If you decide to set run_tfsec to false, this secret does not need to be provided.

terraform-validate.yaml

This workflow will setup and run basic validations for Terraform and optionally Terragrunt if you use it in your repository. If you do not use Terragrunt, all of the inputs with terragrunt in the name are not needed.

If use_terragrunt is set to false, the workflow just do a terraform init and a terraform validate. If use_terragrunt is set to true, a terragrunt init and terragrunt validate will be run, but the Terragrunt-specific check terragrunt hclfmt will also be run.

terraform-validate Inputs

  • terraform_version: The version of Terraform to use when validating. Default: 1.5.5
  • terragrunt_directory: The environment directory from which Terragrunt should run. Default: prod
  • terragrunt_version: The version of Terragrunt to use when validating. Default: 0.48.7
  • use_terragrunt: If set to true, use Terragrunt instead of Terraform. Default: false

Changelog

To generate the CHANGELOG.md, you will need Docker and a GitHub personal access token. We currently use github-changelog-generator for this purpose. The following should generate the file using information from GitHub:

docker run -it --rm \
    -e CHANGELOG_GITHUB_TOKEN='yourtokenhere' \
    -v "$(pwd)":/working \
    -w /working \
    githubchangeloggenerator/github-changelog-generator:latest \
        --verbose \
        --future-release 2.0.0

This will generate the log for an upcoming release of 2.0.0 that has not yet been tagged.

As a note, this repository uses the default labels for formatting the CHANGELOG.md. Label information can be found here: Advanced-change-log-generation-examples

About

GitHub Action workflows that can be shared by multiple repositories

Resources

License

Code of conduct

Stars

Watchers

Forks

Packages

No packages published