Replies: 59 comments 52 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.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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 😭) |
Beta Was this translation helpful? Give feedback.
-
Hi 👋🏻 I've created a terminal tools the manage GitHub Actions more easy. 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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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:
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:
References: |
Beta Was this translation helpful? Give feedback.
-
Is. This. For real? 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. |
Beta Was this translation helpful? Give feedback.
-
And again GitHub doesn't give a sh...t on user requirements :) |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
@kachkaev Are you one of those GitHub guys who doesn't care about user requests? |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
@kachkaev (or anyone in the github dev team) if this is not done then may I at least ask. 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, |
Beta Was this translation helpful? Give feedback.
-
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>
|
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
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