Feature Request: schedule with inputs

[pbrisbin]

Select Topic Area

Product Feedback

Body

I have a few workflows that can be run manually but also run on a schedule:

name: Reset Environment

on:
  workflow_dispatch:
    inputs:
      environment:
        description: "Environment to reset"
        required: true

  schedule:
    - cron: "..." # reset staging every night

Imagine there are many such inputs.

I end up having to basically check for empty inputs and default it to what should be used in the schedule case:

steps:
  - id: prep
    run: |
      env=${{ github.event.inputs.environment }}
      env=${env:-staging} # must be scheduled, reset staging
      echo "env=$env" >>"$GITHUB_OUTPUTS"

  - uses: whatever/whatever@x
    with:
      env: ${{ steps.prep.outputs.env }}

Again, imagine there are many such inputs.

This is cumbersome, hard to reason about, and error-prone. It also means that I can't schedule the workflow additional times with other values. There is only the one "not workflow_dispatch" branch available.

All of this would be solved if schedule elements supported an inputs key that became github.event.inputs when the workflow is executing for that schedule.

Then I could do the following:

name: Reset Environment

on:
 workflow_dispatch:
    inputs:
      environment:
        description: "Environment to reset"
        required: true

  schedule:
    - cron: "..."
      inputs:
        environment: staging # self documenting
    - cron: "..."
      inputs:
        environment: other # not possible before

# ...

steps:
  - uses: whatever/whatever@x # no prep step needed
    with:
      env: ${{ github.event.inputs.environment }}

[pbrisbin]

For future readers, this can be made somewhat nicer by (ab)using env:

name: Reset Environment

on:
 workflow_dispatch:
    inputs:
      environment:
        description: "Environment to reset"
        required: true

  schedule:
    - cron: "..."

env:
  ENVIRONMENT: ${{ github.event.inputs.environment || 'staging' }} # centralize fallbacks

steps:
  - uses: whatever/whatever@x # no prep step needed
    with:
      env: ${{ env.ENVIRONMENT }}

You still cannot do multiple schedules (you only get one fallback-when-unset), nor is it self-documenting in the schedule event definition that the default is "staging". But at least it's a little nicer than an extra prep step and bash substitutions.

[lengau]

Being able to set multiple cron jobs with different inputs would be huge for me. I work with multiple applications where we do weekly regression tests against multiple branches, each of which has a series of settings to configure, but all of which are dependent on just the branch. Having separate cron items where we could spell this out but also being able to customise these values on workflow dispatch would make the configuration much more obvious.

[madkins-webscale]

I'd really love to see this feature too - it'd be great for us who have 20+ test environments and would like to schedule workflows against them

[Mr0grog]

FWIW, I used to use this workaround (setting env vars based on the inputs or event name instead of using the inputs directly) in a lot of places, but have recently started using callable workflows to solve this instead. Instead of scheduling the core workflow, make it callable and then have a separate workflow that gets a schedule event, and which does nothing but call the core workflow. This way, you can clearly set inputs on the scheduled workflow where it calls the core one, and can also set up defaults for the workflow_call event on the core workflow.

I haven’t used it yet, but now that workflows support anchors, you can probably use that to set the same input options for workflow_call and workflow_dispatch, which makes this pattern even nicer.

[scrollDynasty]

While this feature would be great, you can solve this cleanly right now using Reusable Workflows
Keep your main logic in a generic workflow (workflow_call).
Create separate small workflow files for your schedules (e.g., schedule-staging.yml, schedule-other.yml).

on:
  schedule:
    - cron: "0 0 * * *"
jobs:
  reset:
    uses: ./.github/workflows/main-logic.yml
    with:
      environment: staging```

[yogibaba2]

+1

[szwedm]

I think the schedule triggered workflows should at least honor the default values set in workflow_dispatch.inputs or allow to set defaults for schedule (duplication in many cases probably).

[Mr0grog]

I’d echo this but really for all event types, not just schedule. For example, I have a lot of workflows that use both workflow_dispatch and pull_request to do a test run of the workflow on pull requests (I currently check for null input values or for the event name to decide whether to run in a test mode that uses a smaller set of data or doesn’t commit the results, or whatever).