Make something both workflow_call and workflow_dispatch

[sevagh]

Select Topic Area

Question

Body

I have a workflow in a repo using workflow_call and several input parameters; let's call it "repo.yml":

repo $ cat .github/workflows/repo.yml
name: repo workflow

on:
  workflow_call:
    inputs:
      foo:
        type: string
        default: 'bar'

jobs:
  repo-job:
    runs-on: ubuntu-latest
    steps:
      - name: print param
        run: echo "${{ inputs.foo }}"

In a separate 'launcher' repository, I invoke the repo workflow file in launcher.yml, using workflow_dispatch:

launcher $ cat .github/workflows/launcher.yml
name: launcher workflow

on:
  workflow_dispatch:
    inputs:
      repo-foo:
        type: string
        default: 'bar'

jobs:
  repo-job:
    uses: myorg/repo/.github/workflows/repo.yml@main
    with:
      foo: ${{ inputs.repo-foo }}

In this way, I can launch repo.yml from the GitHub Actions UI in the launcher.

Now, I want the original repo to also have a GitHub Actions UI button. Do I simply duplicate all the input parameters?

repo $ cat .github/workflows/repo.yml
name: repo workflow

on:
  workflow_dispatch:
    inputs:
      foo:
        type: string
        default: 'bar'
  workflow_call:
    inputs:
      foo:
        type: string
        default: 'bar'

jobs:
  repo-job:
    runs-on: ubuntu-latest
    steps:
      - name: print param
        run: echo "${{ inputs.foo }}"

[airtower-luna]

Do I simply duplicate all the input parameters?

Yes, exactly. There's no way to share the definitions between triggers. But as long as the inputs are the same the inputs context should work either way. 😅

[suhas-coursera]

Will be good to have a shared_inputs at-least between workflow_call and workflow_dispatch, for anyone who's working on resuable_workflow it'll be much easier to test independently without any duplication in code.

[JoshMcCullough]

Agreed, adding something like a use-call-inputs: true option to workflow_dispatch event and use-dispatch-inputs: true option to workflow_call event would be great!

[marcospb19]

although less versatile, an "allow-manual-dispatch: true" (that turns a workflow_call into both) would be enough for my usage cases.

[vkagarwal-aa]

i have tested and if inputs are same in both workflow_call and workflow_dispatch it works.
another thing to notice if we are using any input type 'choose' in workflow_dispatch, that same input cannot be used in workflow_call.
Alternatively, i have used repository_dispatch in few workflows.

[vkagarwal-aa]

workflow_call:
inputs:
environment:
required: true
type: string

workflow_dispatch:
inputs:
environment:
description: 'Environment'
required: true
type: choice
options:
- "dev"
- "stage"
- "prod"

[csujedihy]

IMO, workflow_dispatch and workflow_call should be further unified. Something like use-call-inputs: true as already mentioned should be provided to avoid code duplication.

[sean-pichardo-kr]

IMO, workflow_dispatch and workflow_call should be further unified. Something like use-call-inputs: true as already mentioned should be provided to avoid code duplication.

Because there might be instances where inputs might not all be shared, ideal would be a: shared_inputs object like previously mentioned, e.g:

shared_inputs: 
  shared_input_foo
  shared_input_bar

workflow_call:
  inputs:
    call_input_baz:
      required: true
      type: string

workflow_dispatch:
  inputs:
    workflow_input_qux:
      required: true
      type: string

[joekiller]

Hello, I found this in googling. Yes the answer is you have to duplicate the inputs.

I wanted to add that for those consuming the workflow_call and workflow_dispatch that you'll likely want to then assign the inputs to an environment variable to ensure that other triggers like, on push or cron will also apply the defaults uniformly.

Use the inputs context in combination with creating an env variable that evaluates using a ternary operation that applies the desired "default" to the environment variable in case of having the action execute outside of workflow_call and workflow_dispatch.

As the examples show using ${{ inputs.VAR }} is more desirable than using ${{ githut.event.inputs.VAR }} context as per on workflow_dispatch inputs:

The information in the inputs context and github.event.inputs context is identical except that the inputs context preserves Boolean values as Booleans instead of converting them to strings.

Ie:

name: repo workflow

on:
  schedule:
    - cron: '0 0 * * *' # 12:00am UTC
  workflow_dispatch:
    inputs:
      foo:
        type: string
        default: 'bar'
  workflow_call:
    inputs:
      foo:
        type: string
        default: 'bar'

# make it so the default for on.schedule we still have a default of 'bar' in `{{ env.foo }}`
env:
  foo: ${{ inputs.foo == null && 'bar' || inputs.foo }}
jobs:
  repo-job:
    runs-on: ubuntu-latest
    steps:
      - name: print param
        run: echo "${{ env.foo }}"

[anusreelakshmi934]

Is it possible to avoid duplication of inputs in workflow_call and workflow_dispatch? Can we use shared_inputs between workflow_call and workflow_dispatch ?

[psychobolt]

I agree would be useful to share inputs, as input list can be quite long...