Skip to content

Workflow Dispatch Inputs

Jump to bottom
mdeguzis edited this page Jul 8, 2026 · 1 revision

Workflow Dispatch Inputs

Every dispatchable pipeline workflow accepts the same three standardized inputs. This lets you spot-fix one issue with a one-click dispatch that comments the run summary back on the target issue.

Standardized by #218.

The three standard inputs

Input Type Purpose
app_ids string, comma-separated Scope the run to specific Steam app IDs. Blank = the workflow's default set (nightly seed / full search index / etc).
issue_id string (numeric) GitHub issue number to comment the run summary back on. Blank = no comment.
dry_run boolean Preview mode: workflow reads upstream data but skips Supabase writes and gh-pages commits. Best-effort per stage.

Not every workflow has an app-scoped meaning -- catalog fetchers and backups run holistically -- so those omit app_ids and only accept issue_id + dry_run. The domain-specific input name is kept where it already exists (backfill_app_ids in update-data.yml, app_ids in steam-metadata-fetch.yml).

Which workflows accept them

Workflow app_ids equivalent issue_id dry_run
update-data.yml backfill_app_ids (domain-specific) yes yes (skips commits + writes per stage)
steam-metadata-fetch.yml app_ids yes yes (fetches PICS but skips Supabase upserts)
content-moderation.yml app_ids (was app_id) yes yes (existing)
backup.yml n/a yes yes (produces artifacts locally, skips upload)
update-epic-catalog.yml n/a yes yes (fetches but skips commit)
update-gog-catalog.yml n/a yes yes (fetches but skips commit)

Discord webhook workflows, deploy-on-merge, sync-staging-main, and retry-pages-build are event reflectors -- they don't take these inputs.

How the issue back-comment works

A shared composite action at .github/actions/back-comment-run/action.yml posts a summary comment when issue_id is set. Every dispatchable workflow calls it at the end of its terminal job with if: always() so a failed run still gets the summary:

- name: Back-comment run summary on issue
  if: always()
  uses: ./.github/actions/back-comment-run
  with:
    issue_id: ${{ inputs.issue_id }}
    status: ${{ job.status }}
    workflow_name: <this-workflow-name>
    app_ids: ${{ inputs.app_ids }}
    dry_run: ${{ inputs.dry_run }}

The comment includes:

  • Status badge (OK, FAIL, CANCEL, or STARTED)
  • Run URL
  • App IDs the dispatch ran against (if any)
  • Whether the run was dry
  • Optional notes passed in by the caller

If issue_id is blank the composite action no-ops -- callers don't need to conditionally include it.

Adding a new dispatchable workflow

  1. Copy the standard inputs block into your workflow_dispatch: trigger:

    workflow_dispatch:
  inputs:
    # ...your workflow-specific inputs...
    issue_id:
      description: "GitHub issue to comment run summary back on (leave blank to skip)"
      required: false
      default: ""
    dry_run:
      description: "Skip writes; preview only"
      type: boolean
      default: false

  2. Grant permissions: issues: write on the job that calls the back-comment action:

    jobs:
  my-job:
    runs-on: ubuntu-24.04
    permissions:
      contents: read
      issues: write
    steps:
      # ...

  3. Add the back-comment step at the end of the job, using if: always().

  4. Guard your write steps with if: inputs.dry_run != true so dispatched previews stay read-only.

  5. tests/workflowDispatchInputs.test.js will fail if you forget any of the above -- add your workflow to the PIPELINE_WORKFLOWS list there.

Rationale

Before #218, verifying a single-issue fix meant editing a workflow, pushing, then reverting. Now the paper trail is automatic and reruns are targeted:

  • File an issue like "Hollow Knight metadata modal shows wrong date"
  • Dispatch steam-metadata-fetch with app_ids=367520 and issue_id=<N>
  • The issue gets an automatic comment linking the run + result
  • Regression sits attached to the ticket forever

Related pages

Clone this wiki locally