Handling multiple PR label triggers?

Is there a better way to handle multiple jobs or workflows that are triggered via labels? We have multiple jobs that can be triggered via PR labels. When any label is added to a PR, all label-triggered jobs get queued even though only one will run and the other jobs gets skipped due to if: github.event.label.name == '<whatever>' conditionals.

This causes confusion in the UI since we routinely add multiple labels to a PR which triggers different jobs, but only the last label added appears with a pass/fail beside the check and the previous checks appear as skipped.

This becomes a larger issue once one of the previous checks fail, there is no way for the PR or user to know it and the PR could be merged when the failed check should have prevented it

# example workflow
name: Label Triggered Workflows

on:
  pull_request:
    types: [labeled]
    branches:
      - '**'
jobs:
  bug_trigger:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo bug
  invalid_trigger:
    if: github.event.label.name == 'invalid'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo invalid
  question_trigger:
    if: github.event.label.name == 'question'
    runs-on: ubuntu-latest
    timeout-minutes: 5
    steps:
      - run: echo question

If I add the labels bug, invalid, then question, the UI only shows this even though all checks were triggered and passed:

Ideally, we should be able to use the if conditional at the parent/workflow level so that the entire workflow is skipped, or be able to specify labels inside of the pull_request block like:

on:
  pull_request:
    types: [labeled]
    branches:
      - '**'
    labels:
      - bug
1 Like

Now, pull_request event doesn’t support filter label name before the workflow be triggered. I would encourage you share your idea in the Feedback form for GitHub Actions.

@nick-invision you are not the only one. We use tagging quite extensively to support concurrent job that are not depend on each other and also build a custom workflows based on different flows.

At the moment we found using labels as a single viable solution where we can trigger multiple workflow at the same time based on a condition without creating large files.

I will follow with the link form @yanjingzhu and provide our feedback describing the same problem.