For organizations that integrate with GitHub App, GitHub OAuth App, Bitbucket Cloud, and Bitbucket Data Center, we now pre-populate pipeline parameters when triggering pipelines in the CircleCI web app.
Users can access this functionality by navigating to the Pipelines page and clicking the ‘Trigger Pipeline’ button, located on the top right of the page. After selecting your branch, if your configuration file has pipeline parameters, it will automatically display in the Parameters section of the modal.
If you encounter any issues or have feedback, comment below or reach out to me at laureen.ma@circleci.com.
1 Like
FYI, this has been scaled down temporarily while we fix a minor bug. We’ll update here when this is rolled back out.
1 Like
This has been rolled back out. Let us know if you run into any issues.
This change is causing chaos for us. We have a lot of parameters in our config, used by various different workflows, many with default values and it now requires a large amount of work for us to remove the params we don’t want when running a specific workflow, otherwise we get weird errors due to params that should not be included for certain workflows being present by default. Can we make this feature optional?
4 Likes
I’m having the same issue, now the users have to delete tons of parameters to run one specific workflow, it will be good if we can mark paramters that should or not be auto loaded to the interface.
2 Likes
This also seems to break out dynamic configuration workflows for some reason (saying the parameters don’t exist in the downstream pipeline)
+1 to it being optional
1 Like
We’re working on adding a Remove all button so users can easily remove all the pre-populated parameters in the modal. We’ll update you when that ability is released.
2 Likes
The ability to remove all parameters has been rolled out. If you have parameters present in the modal, the Remove all button is located to the right of the Add button.
Hey @claassen, email me at laureen.ma@circleci.com with your build link so I can take a closer look at the errors you’re getting.
I actually hate this. I wouldn’t mind a dropdown of available parameters and their types being fixed, but having them automatically set in the UI is breaking continuation workflows, requiring removing conflicting parameters before a manual trigger.
Does clicking the new Remove all button in the modal help resolve the errors you’re encountering with your dynamic configuration workflows?
Based on this feedback, we’re exploring options to remove the auto-populated parameters for dynamic configuration workflows and will keep you updated as we work on a solution.
The remove all button makes things easier. I would prefer that instead of the auto population of all the parameters, the Add button gives me a drop-down or some way of selecting valid parameters for my pipeline.
1 Like
@laureenma the remove all button helps.
We have huge number of parameters in the setup job and depending on the parameter, it gets dispatched to different continuation jobs .e.g continuation 1 requires param foo and bar, continuation 2 requires param abc and def
The current feature sets all the parameter by default, however, this causes issue during continuation, as the pipeline complains about unknown parameter.
For example, this feature sets foo = 1, bar = , abc = true, def = true. If I use this and trigger continuation 1, it will error unknown parameter abc, def.
It takes more time to delete unrelated params than adding new params under the current feature.
A better UI would be the option to conveniently add parameters with predefined drop down.
e.g. add button would give the user the option to choose from a list of predefined parameter (with type and default value). Then user can choose to add them, a search function would also be helpful to make it easier to search for the predefined param I want to add.
Hope that makes sense, let me know if you have any questions
Or even better, scale all the yaml file in .circleci and allow the user to choose which yaml file to pre-populate with
One unfortunate consequence of the new UI is the loss of cached parameters. Previously, the browser would remember the parameters and values entered, automatically refilling the form when opened. This was particularly helpful when fixing minor errors, such as typos, because the form was pre-populated with the last set of parameters. Instead of starting from scratch, I could simply correct the typo and resubmit.
A potential solution could be introducing an option to retain the most recent set of parameter values in the browser cache, at least temporarily until the page is refreshed. Another potential improvement could be a “Reset to Default” button, allowing users to clear cached responses and restore the default values.