workflow_dispatch max inputs from 10 to 25

[igorcosta]

The workflow_dispatch has a soft limit of 10 input parameters.

In a complex deployment environment, this locks migrations or even worst total cancellation of a project. To be fair, there are quite a few scenarios if you're deploying stuff on Actions from AWS Cloudformation or terraform.

What's the workaround on this?

Using a file.json to input the parameter limits and the devs have to change this every single pull request or push.

Is there any other less counter-intuitive way of doing this?

Passing the parameters using the commit message as a JSON object.

A few questions for the product team:

• Why don't you relax the max input parameters to 25?
• What's the reason behind the limit of 10? Security? Cosmetic UI?

Thanks;

[chrispat]

Hi @igorcosta,

Thank you for your feedback. When we shipped the feature we picked what we thought was a reasonable starting limit for inputs based on the scenarios we had envisioned and what we had heard from customers. In addition the UX we have will not scale to dozens of different inputs. We have an item on our backlog to revisit this UX and when we do that we will also look to up the limit on parameters.

For your scenario in particular, the workflow_dispatch inputs are not stored in anyway you can easily retrieve and compare them so there could be some advantage of using a file and PR workflow as you will have a full audit trail of the various deployments and operations.

[sergio-toro]

We are being hit by this limitation as well, overcomplicating our deployment workflows just because you don't know it can be easily solved by adding a simple overflow-y: auto CSS rule.... so excuses about saying it won't scale 🙊

[jsoref]

Having to manually enter > 10 values into any form is incredibly error prone. It kinda doesn't scale by definition. Browsers won't do a particularly good job of saving field values in any remotely useful way for such things. Otoh, building a tiny specific site to generate a single json input for a workflow would be something where browsers could save inputs in a way that kinda works, including bookmarking the page with the last filled in values.

[ghost]

Having to manually enter > 10 values into any form is incredibly error prone.

It can be boolean, choice or number which will reduce a way to make a typo.

Just permit users to do that and they will be responsible for the result.

[jsoref]

I didn't say "typo". I said "error". You can make errors by checking boxes, checking radio items, or entering numbers. https://integrationmadeeasy.com/resources/impact-of-human-error-rates/

According to a study conducted by the Journal of Accountancy, human error rates in manual data entry can range from 1% to 5%, depending on factors such as the complexity of the data and the experience of the data entry personnel.

At 5%, that's 1/20 entries. At 20 entries there's a reasonable chance one of the entries will be incorrect.

[cruizba]

@jsoref This is why you can set default values...

[sgoodman-r7]

@igorcosta I am also running into issues with this.
@chrispat Although the UI seems accept >10 inputs, the workflow immediately fails with
you may only define up to 10 `inputs` for a `workflow_dispatch` event error

[sai-1712]

I'm not able to get multi choice in my actions, can you share your inputs section

[sai-1712]

@igorcosta @ketandoshi @chasemgray @chrispat @sgoodman-r7 check it out, Thank you.

[artem-troitskiy]

It would be great if the limit of workflow dispatch inputs was increased or if a multichoice input type was introduced. I wanted to make it so a user could choose multiple services (we have way more than 10) to release to a chosen environment, but this limitation makes it impossible without some wacky workarounds. As mentioned by savanna-g, UI seems to already work fine with more than 10 inputs, so I hope it is not too hard to implement

[egamezg]

Same way as the other people on the discuss. We need to use more than 10 of different inputs, now using choices, and there is a problem that if the maximum that the worflow_dispatch accepts is only 10. You know if somebody are working on this?

Thanks in advance

[leiarenee]

This is a marketing strategy I guess. They don't want to compete with interface providers.

[DavidJaimesDesign]

And those are?

[paulogodinhoaq]

I would also like to know which ones are you talking about @leiarenee 😃

[kachkaev]

Does anyone know a workaround for defining multiple env vars in one field and parsing them? here is what I mean

Current:

on:
  workflow_dispatch:
    inputs:
      ENV_VAR_A: ## 1
        default: ""
        description: ENV_VAR_A
        required: false
      ENV_VAR_B: ## 2
        default: ""
        description: ENV_VAR_B
        required: false
      ## ...
      ENV_VAR_J: ## 10 🙁
        default: ""
        description: ENV_VAR_J
        required: false

env:
  ENV_VAR_A: ${{ github.event.inputs.ENV_VAR_A }}
  ENV_VAR_B: ${{ github.event.inputs.ENV_VAR_B }}
  ## ...
  ENV_VAR_J: ${{ github.event.inputs.ENV_VAR_J }}

Desired:

on:
  workflow_dispatch:
    inputs:
      env:
        default: ""
        description: all env vars
        required: false

env:
  ## ??

I’d like to be able to set env to ENV_VAR_A=hello ENV_VAR_Z=world and thus avoid the limit of 10 inputs per action.

[Spritekin]

A very simple solution we are using is to base64 encode a yaml file with all the parameters we need. That way we avoid any problems related to quotes, double quotes, spaces, special characters, etc. Example code in no particular language.

myyaml="
---
parameters:
  one: value
  two: ["x", "y", "z"]
moreparameters:
  three: 123
  four:
    something: 'else'
"

myyaml_base64 = base64encode(myyaml)

curl -u "$User:$PAT" \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \
  https://api.github.com/repos/user/repositoryname/actions/workflows/action.yaml/dispatches \
  -d '{"ref": "main", 
       "inputs": {
          "config": "${myyaml_base64}"
        }
  }'

Then in the action I can decode and read using yq or pass to a python script.
Same idea can work with a JSON I guess then decode and read with jq.

[ajeffowens]

The "workaround" that I have implemented, in case it helps, is to use a repository_dispatch trigger instead of workflow_dispatch. This event allows you to use freeform json in the client_payload field of the body.

Example workflow:

---
name:  Build image

on:
  repository_dispatch:
    types: [build]

jobs:
  build:
  
    runs-on: ubuntu-latest

    steps:
    - name: Preparing to build
      run: |
        echo "Image name: ${{ github.event.client_payload.image_name }}"
        echo "Image tag: ${{ github.event.client_payload.image_tag }}"
...

And an example curl to trigger the workflow would be:

curl --location --request POST 'https://api.github.com/repos/OWNER/REPONAME/dispatches' \
--header 'Accept: application/vnd.github.v3+json' \
--header 'Authorization: Bearer <insert personal access token>' \
--data-raw '{
    "event_type": "build",
    "client_payload": {
        "image_name": "test",
        "image_tag": "v1"
      }
    }'

So the event_type field is what determines which exact workflow file will be called. The unfortunate catch with repository_dispatch, however, is that there is no way to target any ref other than the default branch. But this does allow for much larger inputs.

[larswurm]

... and you can only have on repository_dispatch per repo - which is also kind of hampering depending on design and intent...

[chasemgray]

I've also just used a JSON field, but I didn't switch to repository dispatch as was mentioned in the previous answer.

inputs:
    additional_args:
        description: JSON of additional options
        type: string
        default: '{}'
        required: false


// and then later when I want to reference them I use

 ${{ fromJson(inputs.additional_args).parameterName}}

Then later when sending the workflow dispatch

 additional_args: JSON.stringify({
              param: 'test'
})

[RichardWright]

woh, didn't realise you could do this. That's most of the battle there!

[rbarker-dev]

This is awesome.

[ramioh]

Another legitimate use of dispatch_workflow inputs, to run an IaC pipeline against a pre-selected group of infrastructure building blocks. Limiting the number of inputs means that we have to combine some of those blocks and hence waste time executing unnecessary code, not to mention the time wasted on development, of course, just to work around a limitation we never anticipated.

[rmogio-encora]

Any news on this? I'm needing more than 10 inputs in a workflow, and using repository_dispatch won't solve my problem :/

[herereadthis]

An alternative to having more than 10 input options, is implementing a multichoice input type. That way, you can use one input to select a number of options, instead of having a bunch of yes/no choices for each of those options.

Can we implement multichoice?

[vitordeap]

It's covered in this issue actions/runner#2076

[larswurm]

Suggestion / up-vote from my side:

• repository_dispatch - supports that we can send a JSON payload as inparam. Meaning - with "single" inparam the consumer can use payload to form multiple parameters to parse. Limited thing about repository_dispatch is that it is a single / repository (or?)
• workflow_dispatch - really nice, cause you can have multiple dispatchers within single repository but limited again to 10 inparams.

[Spritekin]

I would like to request a review on this one. I really need more than 10 parameters in my workflow_dispatch. Right now in order to reduce my parameter count I had to combine certain related parameters separating the values with a colon. For example software and version parameters are now a single software:version parameter; and a snapshot and uid parameters are now a single snapshot:uid parameter. The problem is then I need to break those in my code.

Note that one of the parameters I pass is a base64 encoded YAML file which allows me to send an unlimited number of parameters, however these parameters in that base64 YAML are what we call implementation specific, while the other 9 are what we call top level engine parameters. What I'm trying to say is: yes I can bypass this limitation but what I get is an ugly and hard to maintain API, while if I had a few more parameters (25 as the OP requested is a very reasonable amount) then my architecture would stay very clean.

Please if you could revisit this limitation.

Thanks,

[nickohold]

As everyone mentioned, we also need way more than 10.
A multiple choice dropdown would be the best option in my opinion. Added bonus if it has a search option that instead of scrolling one by one, you can search for and add selections.
Consider my vote as 10, for all of my team :)

[prein]

An idea. Allow adding freehand key value pairs with predefined list of keys (the inputs defined in the workflow manifests would serve as key names dictionary). Even better - allow specifying which keys are static (always appear) in the form and which dynamic (user clicks "add input" in the bottom of the inputs form to open a new single input entry form with key field suggesting names or being a dropdown) . Perhaps "required" option could be used to control that. The "static"/required inputs can then be limited if there's need for that. But make it tunable (on organization level?)

[Edvinas01]

This limitation seems arbitrary and is greatly limiting our actions.

[vinaykasirala]

+1

[NorseGaud]

+1

[antoineozenne]

+1

[antonFromSnapLogic]

+1

[Ga13Ou]

+1

[murtazakagalwala]

+1

[atri-dastidar-snkeos]

+1

[Nikhil-Shawn]

+1

[annedroiid]

Folks please stop commenting +1. It does nothing to get the issue looked at and just spams anyone following the issue with emails.

[bdelville]

The limitation is officially to reduce the risk of manual error with an arbitrary maximum.

But please note that:
The workaround is the injection of a Json payload. Which is more error prone than removing the arbitrary limitation.

[elmijo]

What's the point to limit the inputs?, furthermore, everyone must take responsibility for their actions, so, thanks thank you for your good intentions in helping us avoid mistakes, but this must be a warning not an error, I would like to take full responsibilities for my mistakes (if I have them), so this must be configurable not an arbitrary imposition.

[nebuk89]

We are working on this currently, hopefully before end of calendar year :)

[nebuk89]

Huh no idea... 😞 My 'enterprise/company' works, what badge do you see for other folks 👀

[nebuk89]

Thats a huge screenshot!! Why so big 😱

[jsoref]

You can set the width=/height= tags if you want to downscale it.

Ok, that's very strange. Compare https://github.com/hubwriter (https://api.github.com/users/hubwriter):

Whereas you seem to be missing it https://github.com/nebuk89 (https://api.github.com/users/nebuk89):

Confusingly, both of you have the site_admin flag set to true, which is I think a good enough signal that you're staff. (Afaiu, the company field is roughly freeform and shouldn't be trusted.)

Do note that you misbranded your employer (twice, in both the job title and the company fields), it should be GitHub not Github -- I wouldn't trust anything written by someone with the wrong branding for a company.

[nebuk89]

Fixed including old typos ;)

[nebuk89]

Thank you for the catch! I honestly hadn't looked at my profile since I joined 4 years ago 😱 thank you all for helping me get this tidy again ❤️

[Numbersf]

We are working on this currently, hopefully before end of calendar year :)

The problem seems to have been solved.

[yukha-dw]

What a time to be alive 🎉🎉🎉

you may only define up to 25 `inputs` for a `workflow_dispatch` event

[nebuk89]

Changelog will come out this Thursday ;) I will close this when it's out

[praveenkumarlodhi979-tech]

Very nice dheere dheere aage badhane ka prayas jari hai ek din kamyabi jarur hasil hogi is tarah ki ummid rakhta hun 💗💗