Replies: 102 comments 92 replies
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@igorcosta I am also running into issues with this. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
This is a marketing strategy I guess. They don't want to compete with interface providers. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
The "workaround" that I have implemented, in case it helps, is to use a Example workflow: And an example curl to trigger the workflow would be: So the |
Beta Was this translation helpful? Give feedback.
-
|
I've also just used a JSON field, but I didn't switch to repository dispatch as was mentioned in the previous answer. Then later when sending the workflow dispatch |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Any news on this? I'm needing more than 10 inputs in a workflow, and using |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
Suggestion / up-vote from my side:
|
Beta Was this translation helpful? Give feedback.
-
|
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, |
Beta Was this translation helpful? Give feedback.
-
|
As everyone mentioned, we also need way more than 10. |
Beta Was this translation helpful? Give feedback.
-
|
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?) |
Beta Was this translation helpful? Give feedback.
-
|
This limitation seems arbitrary and is greatly limiting our actions. |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
+1
|
Beta Was this translation helpful? Give feedback.
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
Folks please stop commenting +1. It does nothing to get the issue looked at and just spams anyone following the issue with emails. |
Beta Was this translation helpful? Give feedback.
-
|
The limitation is officially to reduce the risk of manual error with an arbitrary maximum. But please note that: |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
We are working on this currently, hopefully before end of calendar year :) |
Beta Was this translation helpful? Give feedback.
-
The problem seems to have been solved. |
Beta Was this translation helpful? Give feedback.
-
|
Very nice dheere dheere aage badhane ka prayas jari hai ek din kamyabi jarur hasil hogi is tarah ki ummid rakhta hun 💗💗 |
Beta Was this translation helpful? Give feedback.






Uh oh!
There was an error while loading. Please reload this page.
-
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:
Thanks;
Beta Was this translation helpful? Give feedback.
All reactions