Users can create new pipelines using the Run Pipeline button in the CI/CD > Pipelines page. It is already possible to specify the branch that will be used, but it is not possible to specify new variables for that specific run.
This could be very useful when users need to create a pipeline with "custom" values, in order to affect the behavior without changing the project secret variables for every other run, for example to run only some of the steps or to specify a different parameter for a deployment.
Proposal
Improve the New Pipeline view and allow users to specify variables that will be passed to that specific pipeline run only, in a similar way we already have in the settings page or for scheduled pipelines.
Since the branch is already defined, we don't need to support the protected flag. It could be useful to support the environment scope, but can be decoupled in a different iteration.
Design
This page currently uses a layout with a left column. This needs to be changed to use a one-column layout.
We add a new Variables section with the help text:
Specify variable values to be used on this run. The values specified in CI/CD settings will be used by default.
Linking to PROJECT/settings/ci_cd.
In this section, we have the same component we use in CI/CD settings. Since we will not be doing protected flags or environment scopes in this iteration, those two elements need to be removed from each row.
Every time the user enters a variable name, a new input row is added:
Additional design details
Removal actions are supposed to be represented with a garbage can according to our guidelines. If possible, this MR should switch the current icon out for our own remove.svg. This should happen both in this new page and CI/CD settings.
If possible, the Create for help text should be changed to:
@grzesiek what do you think about that? It would be awesome to specify also environment scope for variables, but it probably requires some additional backend work.
For me, it is very error prone to have to specify the variables manually.
I understand it is a first design, but I don't think it is much more complicated to have a vue component which downloads the .gitlab-ci.yml from the right ref, parses it, and at least pre-populate the variable names (typing is a bit more work indeed)
@tardyp thanks for the feedback. The idea of allowing "free" variables is that you are not forced to define them in a config file, and you can just alter anything you need from there.
Variables may be used inside a script for a job, so there is no way to extract a list of names from the .gitlab-ci.yml file. I suggest we move with the MVC and then we can collect feedback about the usability. If we will figure out that the error rate is very high, we can try to mitigate it in some way.
It's great to see this is coming soon, however there are two things I would add to this if possible...
If global variables are declared in the .gitlab-ci.yml file these should pre-populate the default values visible when you run a new pipeline.
If the defaults are changed this should be flagged using a label in the pipeline (like already exists for latest, error, yaml invalid, etc.), it could just say custom, this could be yellow/orange to differentiate from the existing labels. I also think Scheduled pipelines that change variables should be marked like this too.
Talking of Scheduled pipelines it also makes sense that there is a way to set-up customised pipelines (like asked for in this ticket, and are already available using Scheduled pipelines) that can be triggered from the gitlab UI but are not scheduled to run at any time, i.e. they are only manually triggered - anyway that probably deserves a separate ticket, but as it's closely related I thought it was worth mentioning.
@ayufan I've been working on a Sketch mockup so we can have a precise design, but it's very similar to what's in the description. I'll update it in the next hour I think.
There are three items in the Additional details section that can be taken care of in separate issues, but I wanted to add them to this issue in case it was possible to do some or all of them here.
@tauriedavis would you mind keeping an eye on this issue as well? The proposal is to bring over a component from CI/CD settings and modify it slightly to remove some unnecessary elements. Thanks so much!
@Alex.k877 you can choose the branch name with the top popup.
@annabon The variables are arbitrary, so there is no way to enforce a particular variable to be set in the UI
Is there any way to read parameters key/value pairs with default values from configuration and represent that in pipeline UI? (Like in Jenkins pipeline "parameters" option in groovy)?
That mostly is needed in manual pipeline runs.
I find this feature very lacking...In my manual job I should be able to specify the variables I want a user to supply values for and even provide them a hint in the value field of what to enter. Giving users who run the job a blank sheet of variables to use is almost useless in my eyes. :(
When I retry the execution of a manual job it does not allow me to re-enter any variables and even worse it runs without using the same variable values as the first run. This also makes this feature not very usable. What is the process @bikebilly in gitlab to request this feature to be taken back to the 'drawing board' as there are too many holes in it?
When I click the 'Trigger this manual action' button there can be a delay of up to ~10 seconds for gitlab.com to then show the next page. If this is the case then shouldn't that button be disabled after it is clicked to prevent a user from triggering it accidentally a second time because it is not known to the user that gitlab.com can be slow and the user should simply be waiting.
Again this needs to be improved to be more usable please.
Having the same issue as @skurlow. It's just impossible to do parameterized builds like we are used to in Jenkins. Just some simple steps to enable booleans, checkboxes, dropdowns and strings would help a lot in creating an efficient workflow.
Another idea would be to include a HTML form from the repo on the trigger page (although I could imagine some cross-project security risks w/o URL validation) .. or from external pages, also with CSRF checks.
Showing some job specific help text from the gitlab-ci.yml on the trigger page would also be a good start, though.
The idea is to add a yaml description file (.bod-ui.yml) in your project and the tool will render it as form.
This will ease settings of specific variables in your pipeline
I have a question though; can I have a variable with masked input ? The idea is to allow to input passwords safely ( without having it in clear in the input field ) ...
The problem already starts with the fact that we cannot have manual only pipelines. If we set everything to when: manual and push something, the pipeline will have already started and so you cannot input variables.