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.

[cuongvokatalon]

just hit this, any updates? Thanks

[whibbard-genies]

Bump, also want to see this improved.

[vidhimck09]

Just ran into this, any updates on increasing the input limit?

[mike-gorman-quest]

Even 12 would be better than 10! C'mon, it's just two more.

[hafridi]

Any Updates

[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!

[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?

[videap]

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?)

[james-alford-ln]

Been following this thread for a while now to see if this limitation would be fixed as it causes problems for us. Currently using contains to check a string for certain sub strings but this is horrible and not really scalable as everyone has said. Would be good to understand if there are plans to do something about this!

[cruizba]

Guys, this is so over...

This is now a Christmas thread: Happy Christmas you all 🎄!

(But in the meantime we can complain about the 10 input params. Come on Microsoft, give us a present or something... Just 25 params 😭)

[canack]

Hi 👋🏻 I've created a terminal tools the manage GitHub Actions more easy.
Also this tool parse json input automatically and you can trigger your workflow more easy&fast.
GAMA : https://github.com/termkit/gama

Here is example workflow:

name: Workflow With JSON

on:
  workflow_dispatch:
    inputs:
      services:
        description: "A JSON field for external services"
        required: true
        default: '{
          "backend-ref": "master",
          "frontend-ref": "master",
          "db-scripts-ref": "master"
          }'
      server:
        description: 'Server'
        type: choice
        required: true
        options:
          - '77'
          - '78'
          - '79'
          - '80'
          - '81'
          - '82'
          - '83'
        default: '80'
      version:
        description: 'Version'
        type: string
        required: true
        default: '1.0.0'
      boolean_flag:
        description: 'Boolean Flag'
        type: boolean
        required: true
        default: true
      number:
        description: 'Number'
        type: number
        required: true
        default: 1

The GAMA output:

[igorcosta]

That's very neat @canack

[genkimind]

Guys this is ridiculous, it's 2024 and companies pay for this product. This functionality exists at least in Jenkins and your own ADO Pipelines product.
The fact that I can't have more than 10 input parameters for a manually triggered job is incredible. How can we build our systems off of this in a frictionless way?
Please fix ASAP

[georgegil]

so there I am telling bosses we can migrate all of our ADO pipelines (and repo's) to GH Actions, and boom, ran into this issue.

The response from GitHub on this issue, is frankly just not good enough for the amount of money we pay them!

please fix this.

we're not asking for an unlimited amount, but my god 10?!

that's ridiclous

[Spritekin]

To be honest you have a point... I'm paying thousands of dollars monthly they should at least handle this one.

[claudiofrattarilhv]

So this thread is open from 2 years and half and I can't believe that GitHub Actions still have this huge limit. This product is used and paid by thousand of companies and reusable workflow should be the focus of any actions implementation. The limit of 10 parameters sounds frankly no-sense, sounds like such a simple feature to implements and a lot of clients would benefit.

[Adri99x]

Found some workaround on this issue and it offers a way to dynamically pass all template parameters to a GitHub Action without manually specifying each parameter in the workflow.

Backstage Template (template.yaml):

# ... (existing template definition)

# Trigger a GitHub Action
- id: github-action
  name: Trigger GitHub Action
  action: github:actions:dispatch
  input:
    workflowId: 'deploy.yaml'  # GitHub Action workflow ID
    repoUrl: ${{ parameters.repoUrl }}
    branchOrTagName: 'main'  # The branch to run this action on
    workflowInputs:
      parameters: ${{ parameters | dump }}  # Pass all parameters to the GitHub Action (stringified JSON)

Explanation:

1. Nunjucks Integration: Backstage leverages Nunjucks, allowing you to use Nunjucks filters within your templates. In this case, the dump filter is used to convert the parameters object into a stringified JSON format.
2. Passing Parameters: The dump filter output is assigned to the workflowInputs.parameters key. This effectively passes all template parameters as a single JSON string to the triggered GitHub Action.

GitHub Actions Workflow (deploy.yaml):

# ... (existing workflow definition)

on:
  workflow_dispatch:
    inputs:
      parameters:
        description: 'Parameters for the workflow'
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest

    if: ${{ fromJson(github.event.inputs.parameters).action == 'apply' }}
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: 1.5.7

      - name: Deploy using Terraform
        run: |
          set -eo pipefail
          cd terraform
          ./apply.sh ${{ fromJson(github.event.inputs.parameters).project }} \
            ${{ fromJson(github.event.inputs.parameters).organization_name }} \
            ${{ fromJson(github.event.inputs.parameters).githubToken }} \
          # ... (remaining deployment steps)

Explanation:

1. Receiving Parameters: The workflow receives parameters through the workflow_dispatch trigger. The parameters input captures a JSON string containing all template parameters.
2. Extracting Parameters: The fromJson function from the GitHub Actions context is used to parse the received JSON string back into a usable object. This allows you to access individual template parameters like project, organization_name, and githubToken for example.

References:

1. https://backstage.io/docs/features/software-templates/writing-templates/#built-in-filters
2. https://mozilla.github.io/nunjucks/templating.html#dump

[doojin]

Is. This. For real?
Like actually?

I have an "umbrella" Helm chart. With a lot of highly customizable dependencies. I just wanted to create a workflow to easily setup/update clusters for my clients/users. What do I suppose to do with this 10 inputs limit?

I am soooooo NOT going for the workarounds suggested in the thread. Will have to do it the right way. Which is using something else instead of Github Actions.

[P1119r1m]

And again GitHub doesn't give a sh...t on user requirements :)
Am I surprised?))

[mdepedrof]

I don't understand how this is still in 2024. 3 years later and there is no answer? really? it is the only pipeline system that has this absurd limit and that forces to make complete botches and shit.

[P1119r1m]

@kachkaev Are you one of those GitHub guys who doesn't care about user requests?
It looks silly when you "thumbdowning" all the posts that highlight such ignorance on the part of the GitHub team.

[kachkaev]

I believe there is a knowledge gap in GitHub etiquette, so it might be worth clarifying. Let me explain my 👎 and 😕 reactions to a couple of recent comments.

GitHub discussions work well if all participants follow a few simple rules that keep everyone productive. These rules can be logically derived, there is no secret manual.

When we find a problem that concerns us too, we add 👍 to it as a signal of importance:

Then we usually subscribe to updates to make sure we don't miss a workaround or the resolution.

People who contribute to the conversation should bear in mind that every new message will trigger a notification for fellow developers. For this particular issue, there might be thousands of subscribers, each spending about minute of their time. That’s more than a working day in total, or hundreds of dollars.

If you want to suggest a workaround, share a link to a relevant problem or to help anyhow else, that’s welcomed. If all you want is to post a +1 in an aggressive form, that’s a waste of everyone’s time. Apart from spamming people via notifications, you also make it harder to find replies that may be actually useful:

I’m not affiliated with GitHub, but it’s not too hard to put us in their shoes. GitHub dev teams have limited capacity (as everywhere) and they may use these discussions to prioritise their backlog. Which issues will they choose first: the ones that are respectfully upvoted or the ones that are full of angry spam? As a software developer, would you be willing to work on some feature after you read this:

And again @P1119r1m doesn't give a sh...t on user requirements :)
Am I surprised?))

---

You don’t have to hear what I am trying to say and you don’t have to follow any etiquette whatsoever. But likewise, folks at GitHub don’t owe you anything so you can rant for as long as you want without achieving your goal. Or rather, just be kind to people, don’t spam fellow developers with useless comments and try to contribute in a positive way when you can. Over time, you will see how this pays off and makes you a happier person.

[leiarenee]

If there is a nonsense limit being kept for years for no reason then people have right to show their legitimate reactions to escalate things to poke github support's negligence. How could it be so difficult to increase the limit from 10 to 25.

[github-staff]

Hey folks.

We appreciate all constructive feedback and would like to remind members of our Code of Conduct.

Please remember to contribute in a positive and constructive way and refrain from posting information that is off-topic, which can result in a violation of our Code of Conduct.

[Spritekin]

@kachkaev (or anyone in the github dev team) if this is not done then may I at least ask.
Is this change that hard to make or is it just business decision?

If hard then why? If business, then close the thread and say... won't be done. Just have some empathy with your users and understand is a reasonable request.

Regards,

[jpmaniqis]

simple tao lang poko

…

On Tue, Apr 30, 2024 at 7:57 PM Hammad Afridi ***@***.***> wrote: Any Updates — Reply to this email directly, view it on GitHub <#8774 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BELUIVRN5WJ35RSIQPN7VWLY76BK3AVCNFSM5J5I4ERKU5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSMRXGQ2TSMA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[mike-gorman-quest]

If I may offer $0.02.

First, I think the 10 input limitation is due to a UX usability concern. If the number of inputs for manual execution (workflow_dispatch) is unlimited, the dropdown list of inputs that appears could extend beyond the bottom of the screen. While I can see that is not ideal, probably most of the community would prefer to just leave that up to the workflow author to decide how many inputs is too many.

That said, I have put together the following table to help myself keep up with how many inputs can be declared vs. how many inputs can be passed - as I found the answer depends on what kind of trigger is used:

Now, in no scenario can you ever get a UI dropdown to present the user with more than 10 inputs. What you may be able to do, however, is create different "task-oriented" workflows that all call your "general purpose" workflow.

• The general purpose workflow declares every possible input under workflow_call. Number of inputs here is unlimited.
• Each task-oriented workflow declares up to 10 user-provided inputs via workflow_dispatch and then passes those inputs, along with zero or more hard-coded inputs, to the general-purpose workflow. Total number of inputs the calling workflow can pass to the general-purpose workflow is unlimited.

I think this approach will work for many because, in my experience, when you have a workflow that has more than 10 inputs (mine has 21), many of the inputs are only used for this type of run or that. And when those inputs are used, there's usually another group of inputs that aren't applicable or whose values I don't want to prompt the user for.

So if there's, say, 5 different kinds of tasks my general-purpose workflow is capable of, I'll create 5 task-oriented workflows, each of which can pass the general-purpose workflow values for all 21 inputs. The only limitation is each task can only prompt the user for up to 10 inputs.

Lastly, for cases where we want complete control over interactive execution and ability to pass values for all 21 inputs, we built a stand-alone HTML file with a giant 21-input HTML form that makes an HTTP POST to execute the general-purpose workflow via repository_dispatch. To work around the 10-input maximum that can be passed, we pack most of the inputs into a single input named inputs as a stringified JSON object, as others have suggested.