[Enhancement] Remove assumption that there is a single workflow

[JayyTurakhia]

If I fire a workflow dispatch as uses: benc-uk/workflow-dispatch@v1 with: token: TOKEN workflow: Listen For Trigger

In theory, I can have 2 yamls with the trigger as name: Listen For Trigger on: workflow_dispatch:

The current implementation allows finding only one matching workflow.

I think the enhancement would be in the line const workflowFind = workflows.find((workflow) => workflow.name === workflowRef || workflow.id.toString() === workflowRef)

Can you please let me know if this is a valid request ?

[CWSites]

I also run multiple workflows however I have them broken out in my primary one so I can get alerted if/when one of them fails. I don't think having this trigger multiple workflows is a good idea for debugging and clarity purposes... but that's just my 2 cents.

[JayyTurakhia]

I also run multiple workflows however I have them broken out in my primary one so I can get alerted if/when one of them fails. I don't think having this trigger multiple workflows is a good idea for debugging and clarity purposes... but that's just my 2 cents.

Can you elaborate on what you mean by primary one ? This inherently has a limitation to adding new downstream workflows. If I understand correctly you will need a new trigger in your primary workflow every time you require a new downstream workflow. This has inherent scaling and maintainability issues. My inclination is towards a pub/sub model. A workflow announces a workflow dispatch and whoever is interested can subscribe as a listener

[CWSites]

Sure, here is my setup.

Primary workflow which triggers & waits (version.yml)

jobs:
  # https://github.com/benc-uk/workflow-dispatch
  # this is the workflow trigger which causes my `test.yml` to get run
  verification:
    name: Trigger - Lint, Test & Build
    runs-on: ubuntu-latest

    steps:
      - name: Trigger Workflow
        uses: benc-uk/workflow-dispatch@v1
        with:
          inputs: '{"ref": "${{ github.sha }}"}'
          token: ${{ secrets.REPO_ACCESS_TOKEN }}
          workflow: Lint, Test & Build

  # https://github.com/lewagon/wait-on-check-action
  checks:
    name: Wait on "Lint, Test & Build" Workflow
    runs-on: ubuntu-latest
    needs: [verification]

    # each job on `test.yml` is has it's own wait on check here
    steps:
      - name: wait on build
        uses: lewagon/wait-on-check-action@master
        with:
          ref: ${{ github.sha }}
          check-name: Lint & Build
          repo-token: ${{ github.token }}
          wait-interval: 20

      - name: wait on unit tests
        uses: lewagon/wait-on-check-action@master
        with:
          ref: ${{ github.sha }}
          check-name: Run Unit Tests
          repo-token: ${{ github.token }}
          wait-interval: 20

      - name: wait on e2e tests
        uses: lewagon/wait-on-check-action@master
        with:
          ref: ${{ github.sha }}
          check-name: Run E2E Tests
          repo-token: ${{ github.token }}
          wait-interval: 20

Workflow that is being triggered with 3 individual jobs (test.yml)

name: Lint, Test & Build

on:
  workflow_dispatch:
    inputs:
      ref:
        description: 'GitHub ref to be used for checkout, can be `ref`, `sha` or `branch`'
        required: true

jobs:
  verification:
    name: Lint & Build # used for check-name on version.yml
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.inputs.ref }}

      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 12

      # https://github.com/marketplace/actions/yarn-install-cache
      - name: Cache yarn dependencies
        uses: c-hive/gha-yarn-cache@v1

      - name: Install dependencies
        run: yarn install

      - name: Lint Code
        run: yarn lint

      - name: Build
        run: yarn build
        env:
          CI: true

  unit-tests:
    name: Run Unit Tests # used for check-name on version.yml
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.inputs.ref }}

      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 12

      # https://github.com/marketplace/actions/yarn-install-cache
      - name: Cache yarn dependencies
        uses: c-hive/gha-yarn-cache@v1

      - name: Install dependencies
        run: yarn install

      - name: Run unit tests
        run: yarn test:ci

  e2e:
    name: Run E2E Tests # used for check-name on version.yml
    runs-on: ubuntu-latest

    steps:
      - name: Checkout source code
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.inputs.ref }}

      - name: Setup Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 12

      # https://github.com/marketplace/actions/yarn-install-cache
      - name: Cache yarn dependencies
        uses: c-hive/gha-yarn-cache@v1

      - name: Install dependencies
        run: yarn install

      - name: Increase watchers
        run: echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

      - name: Run e2e tests
        run: yarn e2e:ci
        env:
          CI: true

[JayyTurakhia]

I understand your setup. Now imagine having 3 more things post build. Like pushing docker containers, publishing nugets, sending slack notifications etc.. This workflow file will keep growing becoming unmanageable. Also consider the fact that this "test.yml" may be applicable to 120 repos in an organizational setup.

Ideally you want to have "test.yml", "lint.yml", "build.yml" all 3 triggered from a single pub from "version.yml". Maybe this a design choice whether you want to have a gigantic file. Or smaller files. I prefer the latter, hence the request

[CWSites]

I do have post build stuff going on, I just included the relevant portion that gets the point across. You can trigger and wait on as many workflows as you like which will allow you to break it all down into multiple files. I actually have multiple workflows calling my test.yml and you could break it out even further. For me it didn't make sense so I have all 3 in one file.

If you have one workflow that sends out a global "run all the things" and you have 15 files listening for that command wouldn't that be even more complex to maintain? What if you need to run 14 out of 15 files, then you have to come up with a specific way to differentiate, etc.

[benc-uk]

In v1.2 you can reference the workflow by filename