Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/staffbase/gha-workflows

Repository to manage all reusable workflows
https://github.com/staffbase/gha-workflows

actions github-actions github-workflows reusable-workflows

Last synced: 5 months ago
JSON representation

Repository to manage all reusable workflows

Awesome Lists containing this project

README 

          
# Reusable Workflows from the Enthusiasts 🎉



The repository contains all general workflows which can be used for every workflow in another repository.

If you want to have more information you can take a look at the [GitHub documentation][reusable-workflows].



If you want to use a template workflow you can copy the following template and adapt it to your specific use case.

You can find all possible template workflows in the directory `.github/workflows` with the name `template_*.yml`.



```yml

name: 



on:

  ...



jobs:

  :

    uses: Staffbase/gha-workflows/.github/workflows/template_*.yml@v7.9.0

    with:

      ...

```



## Example Configurations 🔧



In this section you can find examples of how to use template workflows. For more information, please take a look at the templates.



### Auto-Merge Dependabot



The action can be used to auto-merge a dependabot PR with minor and patch updates.



The action is called by creating a PR. It is necessary that the repository is enabled for auto-merge.

Afterward the PR will be merged with the help of the merge queue if all required conditions of the repository are fulfilled.



⚠️ You can also force a merge of a PR. This means that the PR will immediately be merged.

If you want to enable the force merge, make sure that the app can bypass any protection rules.



```yml

name: Enable Dependabot Auto-Merge



on:

  pull_request:

    types: [opened]



jobs:

  dependabot:

    uses: Staffbase/gha-workflows/.github/workflows/template_automerge_dependabot.yml@v7.9.0

    with:

      # optional: ⚠️ only enable the force merge if you want to do the merge just now

      force: true

      # optional: choose strategy when merging (default: squash)

      strategy: rebase, merge

      # optional: choose which types of update you want to allow (default: minor,patch)

      update-types: major,minor,patch

      # optional: choose if you want to allow versions with semver 0.X.X (default: false)

      include-pre-release: true

    secrets:

      # identifier of the GitHub App for authentication

      app_id: ${{  }}

      # private key of the GitHub App

      private_key: ${{  }}

```



### AutoDev



The action can be used to merge labeled pull requests into a branch.



```yml

name: Autodev

on:

  push:

    branches-ignore:

      - dev

  pull_request:

    types: [labeled, unlabeled, closed]



jobs:

  autodev:

    uses: Staffbase/gha-workflows/.github/workflows/template_autodev.yml@v7.9.0

    with:

      # optional: base branch from which the history originates, default: main

      base: master

      # optional: name of the dev branch, default: dev

      branch: your dev branch

      # optional: update status comment, default: false

      # if you want to change the message, please adapt 'success_comment' and/or 'failure_comment'

      comments: true

      # optional: update status label, default: false

      # if you want to change the labels, please adapt 'success_label' and/or 'failure_label'

      labels: true

      # optional: label which should trigger the action, default: dev

      label: deploy

      # optional: name of the user which does the commit, default: AutoDev Action

      user: your name

      # optional: mail of the user which does the commit, default: staffbot@staffbase.com

      email: your mail

      # optional: path relative to the repo root dir in which the GitOps action should be executed, default: .

      working-directory: ./my-service-folder

    secrets:

      # optional: access token to fetch the pull requests

      token: ${{  }}

      # optional: identifier of the GitHub App for authentication

      app_id: ${{  }}

      # optional: private key of the GitHub App

      private_key: ${{  }}

```



### Changeset Check



The action can be used to check a PR for the existance of changeset files. It will then add/update a comment on the PR.



```yml

name: Changeset Check

on:

  pull_request:

    types: [opened, reopened, synchronize]



jobs:

  changeset-check:

    uses: Staffbase/gha-workflows/.github/workflows/template_changeset_check.yml@v7.9.0

```



### Changeset Release



The action can be used to create release PR and publish releases for repos using PNPM and changesets.



⚠️ Make sure you have `@changesets/cli` installed as a dev-dependency in your project!



```yml

name: Release Changesets



on:

  push:

    branches:

      - main



jobs:

  changeset-release:

    uses: Staffbase/gha-workflows/.github/workflows/template_changeset_release.yml@v7.9.0

    with:

      # optional: The file containing the Node.js version to use, defaults to .nvmrc

      node-version-file: '.node-version'

      # optional: The script to run on publish. Defaults to `pnpm release`

      publish-script: 'pnpm publish'

      # optional: The script to run for bumping the package versions. Defaults to `pnpm changeset version`

      version-script: 'pnpm version'

      # optional: The registry to use for Node.js packages.

      node-registry: 'https://npm.pkg.github.com/'

      # optional: The scope to use for Node.js packages.

      node-registry-scope: '@staffbase'

    secrets:

      # identifier of the GitHub App for authentication

      app-id: ${{  }}

      # private key of the GitHub App

      private-key: ${{  }}

      # needs write:packages rights

      npm-token ${{  }}

```



### Find Flaky Tests



The action can be used to find flaky tests.



```yml

name: Find flaky tests



on:

  # At 05:00 on Monday.

  schedule:

    - cron: '0 5 * * 1'



jobs:

  flaky-tests:

    uses: Staffbase/gha-workflows/.github/workflows/template_flaky_tests.yml@v7.9.0

    with:

      # identifier for the slack channel

      slack-channel-id: 45678787976

      # name of the slack channel

      slack-channel-name: '#flaky-tests'

      # optional: name of the repository where it should check, default: current repository

      repository: 'Staffbase/test-flaky'

      # optional: name of the branch where it should check, default: main

      branch: 'master'

      # optional: file path suffixes (comma seperated) to filter the test files

      path-suffixes: ".spec.ts,.spec.tsx,.test.ts,.test.tsx"

      # prefix of the test run which should be filtered out

      prefix: 'test-'

    secrets:

      # URL of the Slack incoming webhooks

      slack-incoming-webhooks-url: ${{ secrets.SLACK_INCOMING_WEBHOOKS_URL }}

      # GitHub token

      token: ${{ secrets.GITHUB_TOKEN }}

```



### GitOps



The action can be used to build and publish a docker image.



```yml

name: GitOps

on: [ push ]



jobs:

  gitops:

    uses: Staffbase/gha-workflows/.github/workflows/template_gitops.yml@v7.9.0

    with:

      # optional: host of the docker registry, default: "staffbase.jfrog.io"

      docker-registry: ""

      # optional: list of build-time variables

      docker-build-args: |

        "any important args"

      # optional: set the target stage to build

      docker-build-target: "any target"

      # optional: set the provenance level of the docker build, default: "false"

      docker-build-provenance: ""

      # optional: should the last stage image be retagged for the release image, default: false

      docker-disable-retagging: true

      # optional: path to the Dockerfile, default: ./Dockerfile

      docker-file: 

      # optional: name of the docker image, default: private/

      docker-image: 

      # optional: custom tag for the productive docker image which is preferred over the tag generated by the workflow

      docker-custom-tag: 

      # optional: organization of the gitops repository, default: github.repository_owner

      gitops-organization: 

      # optional: repository where to update the files, default: mops

      gitops-repository: ""

      # optional: user which does the commit, default: "staffbase-actions"

      gitops-user: ""

      # optional: email of the user which does the commit, default: "staffbase-actions[bot]@users.noreply.github.com"

      gitops-email: ""

      # optional: files which should be updated for dev

      gitops-dev: |-

        your files

      # optional: files which should be updated for stage

      gitops-stage: |-

        your files

      # optional: files which should be updated for prod

      gitops-prod: |-

        your files

      # optional: defines the github runner for the gitops step

      runs-on: ubuntu-latest

      # optional: Upwind.io client ID

      upwind-client-id: ${{ vars.UPWIND_CLIENT_ID }}

      # optional: Upwind.io organization ID

      upwind-organization-id: ${{ vars.UPWIND_ORGANIZATION_ID }}

    secrets:

      # optional: username for the docker registry

      docker-username: ${{  }}

      # optional: password for the docker registry

      docker-password: ${{  }}

      # optional: list of secrets to expose to the build (e.g., key=string, GIT_AUTH_TOKEN=mytoken)

      docker-build-secrets: |

        "${{  }}"

      # optional: list of secret files to expose to the build (e.g., key=filename, MY_SECRET=./secret.txt)

      docker-build-secret-files: |

        "${{  }}"

      # optional: token to access the repository

      gitops-token: ${{  }}

      # optional: gonosumdb environment variable

      gonosumdb: ${{  }}

      # optional: identifier of the GitHub App for authentication

      app-id: ${{  }}

      # optional: private key of the GitHub App

      private-key: ${{  }}

      # optional: Upwind client secret

      upwind-client-secret: ${{ secrets.UPWIND_CLIENT_SECRET }}

```



### Jira Ticket Tagging



The action can be used to collect all jira issues between the last two tags created.

Then the jira issues will be updated with a release date and the labels will be tagged with the current tag name.



```yml

name: Annotate Jira Issues

on:

  push:

    tags: ['**']



jobs:

  jira_annotate:

    uses: Staffbase/gha-workflows/.github/workflows/template_jira_tagging.yml@v7.9.0

    with:

      # optional: name of the service to add as label, default: name of the repository

      name: 'component name'

      # optional: regex to match the tags

      tag-matcher: your regex

    secrets:

      # basic url for jira api

      jira-url: ${{  }}

      # api token for jira usage

      jira-token: ${{  }}

      # email of the api token owner

      jira-email: ${{  }}

```



### LaunchDarkly Code References



The action can be used to collect and push code references for LaunchDarkly feature flags.



```yml

name: Find LaunchDarkly flag code references

on:

  push:

    branches:

      - main



jobs:

  ld_code_references:

    uses: Staffbase/gha-workflows/.github/workflows/template_launchdarkly_code_references.yml@v7.9.0

    with:

      # optional: key of the LD project, default: default

      project-key: 'my-project'

    secrets:

      # LD access token with correct access rights

      access-token: ${{  }}

```



### Merge Block



The action can be used to block the merge if a do not merge label is set.



```yml

name: Merge Block



on:

  pull_request:

    types: [opened, labeled, unlabeled]



jobs:

  block:

    uses: Staffbase/gha-workflows/.github/workflows/template_merge_block.yml@v7.9.0

    with:

      # optional: name of the label if the PR should not be merged, default: do not merge

      label: merge block

      # optional: comment when the PR is blocked, default: true

      comment: false

```



### Release Drafter



The action can be used to draft automatically a new release.



If you want to use the template action please note that you must have the configuration file `.github/release-drafter.yml`.

More information on how to configure this file can be found [here](https://github.com/marketplace/actions/release-drafter#configuration).



```yml

name: Release Drafter



on:

  push:

    branches:

      - main



jobs:

  update_release_draft:

    uses: Staffbase/gha-workflows/.github/workflows/template_release_drafter.yml@v7.9.0

    with:

      # optional: name of the release drafter configuration file, default: release-drafter.yml

      config-name: release-drafter-test.yml

      # optional: name of the release

      name: Version X.Y.Z

      # optional: should the release be published, default: false

      publish: true

      # optional: tag name of the release

      tag: vX.Y.Z

      # optional: version to be associated with the release

      version: X.Y.Z

      # optional: prerelease status of the release, default: false

      prerelease: true

      # optional: prerelease identifier of the release

      prerelease-identifier: alpha

    secrets:

      # optional: access token for the release drafter

      token: ${{  }}

      # optional: identifier of the GitHub App for authentication

      app_id: ${{  }}

      # optional: private key of the GitHub App

      private_key: ${{  }}

```



### Release Version Detector



The action can be used to get the next version for a service.



The new version is in the format `YEAR.WEEK.COUNTER`. You will get the version as output with the key `new_version` and the new tag with the key `new_tag`.

You can remove all other version resolver from your configuration.



```yml

name: Release Version Detector



on:

  push:

    branches:

      - main



jobs:

  new_version:

    uses: Staffbase/gha-workflows/.github/workflows/template_release_version.yml@v7.9.0

    with:

      # optional: format of the version, default: weekly

      format: 'quarterly'

```



You could use the action in combination with the reusable release drafter.

Make sure to add the following lines to update the week number correctly for a draft release.



```yml

on:

  schedule:

    # run every Monday at midnight and every new year to ensure the draft release have the correct week number

    - cron: '0 0 * * 1'

    - cron: '0 0 1 1 *'

```



### Secret Scanning



This workflow should be called by a PR and will scan it's commits for leaked credentials. The workflow will fail if any results are found.



```yml

name: Secret Scan



on: [pull_request]



jobs:

  trufflehog:

    uses: Staffbase/gha-workflows/.github/workflows/template_secret_scan.yml@v7.9.0

```



### Stale



The action can be used to close old pull requests or issues automatically after a few days.



```yml

name: Stale PRs



on:

  schedule:

    - cron: "0 0 * * 1-5"



jobs:

  stale:

    uses: Staffbase/gha-workflows/.github/workflows/template_stale.yml@v7.9.0

    with:

      # optional: comment on the stale pull request while closed, default: This stale PR was closed because there was no activity.

      close-pr-message: your message

      # optional: idle number of days before marking pull requests stale, default: 60

      days-before-pr-stale: 30

      # optional: delete branch after closing the pull request, default: true

      delete-branch: false

      # optional: labels on pull requests exempted from stale

      exempt-pr-labels: your labels

      # optional: label to apply on staled pull requests, default: stale

      stale-pr-label: staling

      # optional: comment on the staled pull request, default: This PR has been automatically marked as stale because there has been no recent activity in the last 60 days. It will be closed in 7 days if no further activity occurs such as removing the label.

      stale-pr-message: your message

```



### TechDocs Monorepo (Azure)



This GitHub Action can be used for generating and publishing Backstage TechDocs for a monorepo. It is limited to an Azure Storage account.



```yml

name: TechDocs



on:

  push:

    branches:

      - 'main'

    paths:

      - "docs/**"

      - "mkdocs.yml"

      - ".github/workflows/techdocs.yaml"



jobs:

  techdocs:

    uses: Staffbase/gha-workflows/.github/workflows/template_techdocs_monorepo.yml@v7.9.0

    secrets:

      # required: specifies an Azure Storage account name

      azure-account-name: ${{ vars.TECHDOCS_AZURE_ACCOUNT_NAME }}

      # required: specifies the access key associated with the storage account

      azure-account-key: ${{ secrets.TECHDOCS_AZURE_ACCESS_KEY }}

```



### TechDocs



This GitHub Action can be used for generating and publishing Backstage TechDocs.



```yml

name: TechDocs



on:

  push:

    branches:

      - 'main'

    paths:

      - "docs/**"

      - "mkdocs.yml"

      - ".github/workflows/techdocs.yaml"



jobs:

  techdocs:

    uses: Staffbase/gha-workflows/.github/workflows/template_techdocs.yml@v7.9.0

    with:

      # optional: kind of the Backstage entity, default: Component

      # ref: https://backstage.io/docs/features/software-catalog/descriptor-format#contents

      entity-kind: Component

      # optional: name of the Backstage entity, default: repository name

      entity-name: custom-entity-name

      # optional: list of space separated additional python plugins to install

      additional-plugins: 'mkdocs-minify-plugin\>=0.3'

    secrets:

      # optional: specifies an Azure Storage account name

      azure-account-name: ${{ vars.TECHDOCS_AZURE_ACCOUNT_NAME }}

      # optional: specifies the access key associated with the storage account

      azure-account-key: ${{ secrets.TECHDOCS_AZURE_ACCESS_KEY }}

```



### Terraform Format



This GitHub Action checks the formatting of Terraform files and commit fixes if necessary.



```yml

name: Terraform



on: [pull_request]



jobs:

  terraform:

    uses: Staffbase/gha-workflows/.github/workflows/template_terraform_format.yml@v7.9.0

    with:

      # optional: Terraform version, default: latest

      terraform-version: latest

      # optional: Committer name, default: staffbase-actions[bot]

      committer-name: staffbase-actions[bot]

      # optional: Committer email, default: staffbase-actions[bot]@users.noreply.github.com

      committer-email: staffbase-actions[bot]@users.noreply.github.com

    secrets:

      # GitHub App is required because GITHUB_TOKEN will not trigger new actions

      app-id: ${{  }}

      private-key: ${{  }}

```



### TestIO



This GitHub Action can be used to trigger a test on the external crowd-testing platform TestIO from a pull request.



```yml

name: TestIO - Trigger test from PR

on:

  issue_comment:

    types: [created, edited]



jobs:

  trigger-testio-test:

    uses: Staffbase/gha-workflows/.github/workflows/template_testio_trigger_test.yml@v7.9.0

    with:

      # optional: the slug you received from TestIO, defaults to 'staffbase'

      testio-slug: your TestIO slug

      # ID of the product on the TestIO platform to which the triggered test should be assigned to

      testio-product-id: your product ID

    secrets:

      # GitHub token to be used for commenting in a PR

      github-token: ${{ secrets.GITHUB_TOKEN }}

      # TestIO token of a user for which the triggered test is created

      testio-token: ${{ secrets.TESTIO_TOKEN }}

```



### Yamllint



The action can be used to check yaml files for formatting.



```yml

name: YAMLlint



on:

  push:

    branches:

      - '**'

    tags-ignore:

      - '**'



jobs:

  yamllint:

    uses: Staffbase/gha-workflows/.github/workflows/template_yaml.yml@v7.9.0

    with:

      # optional: name of the running action, default: yamllint / yamllint

      action-name: your name

      # optional: path which files should be checked recursively, default: .

      target-path: your path

```



## Limitations 🚧



With the current implementation of the reusable workflows from GitHub, we have some usage limitations.



- It isn't possible to [access environment variables][reusable-workflow-env] and [secrets][reusable-workflow-secrets], so it's necessary to pass them to the workflow. But we don't want to do it for all secrets.



There are also some [further limitations][further-limitations] if you want to use the `GITHUB_TOKEN`.



## Release 🔖



To create a new release just use [this page][release-new] and publish the draft release.



## Contributing 👥



Please read [CONTRIBUTING.md](CONTRIBUTING.md) for details on our code of conduct, and the process for submitting pull requests to us.



## License 📄



This project is licensed under the Apache-2.0 License - see the [LICENSE.md](LICENSE) file for details.



  

    

      Staffbase GmbH

    

    

      Staffbase GmbH

      
Staffbase is an internal communications platform built to revolutionize the way you work and unite your company. Staffbase is hiring: staffbase.com/jobs

      
GitHub | Website | Jobs

    

  



[reusable-workflows]: https://docs.github.com/en/actions/learn-github-actions/reusing-workflows

[release-new]: https://github.com/Staffbase/gha-workflows/releases

[reusable-workflow-secrets]: https://github.com/orgs/community/discussions/17554

[reusable-workflow-env]: https://github.com/orgs/community/discussions/26671

[further-limitations]: https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow