I’ve just come off of a small project where we used manually-triggered workflows for things like deploys and database migrations, and our workflow looked something like this:

on:
  repository_dispatch:
    types: db-migrate
jobs:

migrate:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- run: |

script/db-migrate ${{github.event.client_payload.direction}} 

--count ${{github.event.client_payload.count}} 

--env ${{github.event.client_payload.env}}

This workflow will run on the “repository_dispatch” event when the type is “db-migrate”—there are also other expected payload values such as “direction”, “count”, and “env” which dictated various aspects of our migrations.

I wrote a small tool, dpx, whose purpose it is to make sending these dispatch events easier:

dpx -r owner/repo -t $github_token db-migrate direction=up count=1 env=prod

Since you asked, you could also set environment variables using this, if need be:

on:
  repository_dispatch:
    types: db-migrate
jobs:

migrate:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- run: echo "::set-env name=DB_HOST::${{github.event.client_payload.DB_HOST}}"

- run: |

script/db-migrate ${{github.event.client_payload.direction}} 

--count ${{github.event.client_payload.count}} 

--env ${{github.event.client_payload.env}}

See the ::set-env documentation for more info on that, but the idea is that we’re setting an environment variable whose value is something provided in the repository dispatch payload.

Thank you very much for pointing me on this event. I missed it. It looks like what I needed. 

Thank you for sharing your CLI tool and workflow examples!