Skip to content

Repository to manage all reusable workflows

License

Notifications You must be signed in to change notification settings

Staffbase/gha-workflows

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

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.

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.

name: <your name>

on:
  ...

jobs:
  <action name>:
    uses: Staffbase/gha-workflows/.github/workflows/template_*[email protected]
    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.

name: Enable Dependabot Auto-Merge

on:
  pull_request:
    types: [opened]

jobs:
  dependabot:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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: ${{ <your-app-id> }}
      # private key of the GitHub App
      private_key: ${{ <your-private-key> }}

AutoDev

The action can be used to merge labeled pull requests into a branch.
name: Autodev
on:
  push:
    branches-ignore:
      - dev
  pull_request:
    types: [labeled, unlabeled, closed]

jobs:
  autodev:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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: [email protected]
      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: ${{ <your-token> }}
      # optional: identifier of the GitHub App for authentication
      app_id: ${{ <your-app-id> }}
      # optional: private key of the GitHub App
      private_key: ${{ <your-private-key> }}

GitOps

The action can be used to build and publish a docker image.
name: GitOps
on: [ push ]

jobs:
  gitops:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    with:
      # optional: host of the docker registry, default: "staffbase.jfrog.io"
      docker-registry: "<your-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: "<your-provenance-level>"
      # 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: <path-to-Dockerfile>
      # optional: name of the docker image, default: private/<repository_name>
      docker-image: <your-image>
      # optional: custom tag for the productive docker image which is preferred over the tag generated by the workflow
      docker-custom-tag: <your-tag>
      # optional: organization of the gitops repository, default: github.repository_owner
      gitops-organization: <your-organization>
      # optional: repository where to update the files, default: mops
      gitops-repository: "<your-repository>"
      # optional: user which does the commit, default: "staffbase-actions"
      gitops-user: "<your-user>"
      # optional: email of the user which does the commit, default: "staffbase-actions[bot]@users.noreply.github.com"
      gitops-email: "<your-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: 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: ${{ <your-docker-username> }}
      # optional: password for the docker registry
      docker-password: ${{ <your-docker-password> }}
      # optional: list of secrets to expose to the build (e.g., key=string, GIT_AUTH_TOKEN=mytoken)
      docker-build-secrets: |
        "${{ <your-secrets> }}"
      # optional: list of secret files to expose to the build (e.g., key=filename, MY_SECRET=./secret.txt)
      docker-build-secret-files: |
        "${{ <your-secret-files> }}"
      # optional: token to access the repository
      gitops-token: ${{ <your-gitops-token> }}
      # optional: gonosumdb environment variable
      gonosumdb: ${{ <your-gonosumdb> }}
      # optional: identifier of the GitHub App for authentication
      app-id: ${{ <your-app-id> }}
      # optional: private key of the GitHub App
      private-key: ${{ <your-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.
name: Annotate Jira Issues
on:
  push:
    tags: ['**']

jobs:
  jira_annotate:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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: ${{ <your-url> }}
      # api token for jira usage
      jira-token: ${{ <your-token> }}
      # email of the api token owner
      jira-email: ${{ <your-email> }}

LaunchDarkly Code References

The action can be used to collect and push code references for LaunchDarkly feature flags.
name: Find LaunchDarkly flag code references
on:
  push:
    branches:
      - main

jobs:
  ld_code_references:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    with:
      # optional: key of the LD project, default: default
      project-key: 'my-project'
    secrets:
      # LD access token with correct access rights
      access-token: ${{ <your-access-token> }}

Merge Block

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

on:
  pull_request:
    types: [opened, labeled, unlabeled]

jobs:
  block:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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.

name: Release Drafter

on:
  push:
    branches:
      - main

jobs:
  update_release_draft:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    with:
      # 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
    secrets:
      # optional: access token for the release drafter
      token: ${{ <your-token> }}
      # optional: identifier of the GitHub App for authentication
      app_id: ${{ <your-app-id> }}
      # optional: private key of the GitHub App
      private_key: ${{ <your-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.

name: Release Version Detector

on:
  push:
    branches:
      - main

jobs:
  new_version:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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.

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.
name: Secret Scan

on: [pull_request]

jobs:
  trufflehog:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]

Stale

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

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

jobs:
  stale:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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

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

on:
  push:
    branches:
      - 'main'
    paths:
      - "docs/**"
      - "mkdocs.yml"
      - ".github/workflows/techdocs.yaml"

jobs:
  techdocs:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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: ${{ secrets.TECHDOCS_AZURE_ACCOUNT_NAME }}
      # optional: specifies the access key associated with the storage account
      azure-account-key: ${{ secrets.TECHDOCS_AZURE_ACCESS_KEY }}

TestIO

This GitHub Action can be used to trigger a test on the external crowd-testing platform TestIO from a pull request.
name: TestIO - Trigger test from PR
on:
  issue_comment:
    types: [created, edited]

jobs:
  trigger-testio-test:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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.
name: YAMLlint

on:
  push:
    branches:
      - '**'
    tags-ignore:
      - '**'

jobs:
  yamllint:
    uses: Staffbase/gha-workflows/.github/workflows/[email protected]
    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.

There are also some further limitations if you want to use the GITHUB_TOKEN.

Release πŸ”–

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

Contributing πŸ‘₯

Please read 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 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