CODEWITHSUNDEEP
github-actions
samba2
samba2

Reputation: 622

Run Github workflow on non-default branch

We have the current branch setup for our IaC repository:

Inside the "int" and "prod" branch, we currently don't have any Github workflows stored. On the "dev" branch, we have the workflow .github/workflows/check.yaml with the following event config:

on: 
  workflow_dispatch:
  pull_request:
    branches:
      - dev
      - int
      - prod
    paths:
      - '**/some-config-to-be-tested.json'

PRs against "dev" branch run the workflow as expected.

Current issue We also want this workflow to run on PRs against the "int" and "prod" branches without duplicating the workflow. For example, the workflow should run on a PR to get branch "feature/new-int-config" merged to "int" branch. However, this is not the case. PRs against "int" and "prod" do not run the workflow. In fact, the "checks" tab of the PR shows "0".

Manual trigger: Furthermore, when trying to manually run the workflow on a branch not containing the workflow (as it was branched off of "int"), I get this error: Workflow does not exist or does not have a workflow_dispatch trigger in this branch.

I probably could work around this by copying the workflow from "dev" to "int" and "prod" but I really like to avoid this duplication and instead have the workflow in a single location.

What are your suggestions ?

Upvotes: 0

Views: 187

Answers (1)

Delta George
Delta George

Reputation: 4236

GitHub Actions does not support a scenario where you have three independent branches and only one branch has a workflow. If you can not see a workflow on an int or prod branch, the same is true for GitHub Actions. Therefore, that workflow can only run on dev branch.

A better solution would be to create a reusable workflow that is placed on a workflow branch while the three branches have a simple wrapper workflow that invokes the reusable workflow. All logic will be shared across branches without duplication. The wrapper workflows will simply have workflow triggers as you showed in your question and a one-line job that invokes a reusable workflow:

name: dev-workflow

on:
  workflow_dispatch:
  pull_request:
    branches:
      - dev
      - int
      - prod
    paths:
      - '**/some-config-to-be-tested.json'

jobs:
  invoke-check:
    uses: org/repo/.github/workflows/check.yaml@v1
    with:
      branch: dev

A reusable workflow is the same as a regular workflow but with a workflow_call trigger:

name: check

on:
  workflow_call:
    inputs:
      branch:
        required: true
        type: string

jobs:
  ...

This workflow resides on a dedicates branch and is tagged as v1. The tag is progressed as the workflow is modified. A branch called v1 would work just as well without the need to push the tag along. However, the tag allows to release a stable workflow version while the workflow is being developed further.

There is a small catch as well. int-check and prod-check workflows must be present on the default branch (dev in your case) in order to be visible in the UI for manual triggering. These versions of the workflows will never be run. They simply give GitHub Actions a list of workflows that are available in the repo. This list gets displayed in the UI. These workflows can be minimal.

Upvotes: 1

Related Questions