Recently implemented Specify variables when running a manual job provided an ability to specify additional job parameters when running a manual job via UI, however when retrying a failed manual job neither previously specified parameters are reused nor is it possible to provide different parameters.
#327347 (closed) is created to address failure to reuse original variables specified.
Intended users
Unknown
In our particular delivery process Release Manager needs to be able to provide additional information when publishing a tested build to the customer, which is implemented via running a manual job.
Further details
Allow to correct mistakes in the originally specified manual job parameters
Proposal
Permissions and Security
Existing permissions for running manual jobs seem to be applicable here as well
Documentation
Potentially new UI documentation may be required
Testing
What does success look like, and how can we measure that?
Given a finished (either successful or failed) manual job exists, when a user with necessary permissions to retry the given manual job wants to retry the job, then the system provide an ability to specify additional job variables parameters.
I think I found a workaround, though there are many ways to retry such job and only one of them succeeds. It is very misleading!
Working:
Go to the pipeline screen, eg. by clicking pipeline id on failed job screen, or finding pipeline in question on the pipelines list.
There, click retry. Wait till a new job is created for the manual pipeline step. As far as I can tell, this does not retry steps already done, only the failed steps. It can have side effects if there are more failed steps though!
Click on the new job, pass parameters and run it.
Not working:
Pressing retry on the failed manual job (doesn't allow to pass new values)
Sometimes working?
Clear logs of the failed manual job, then provide new values for the variables. (My guess is - it allows to change values of variables passed on the first run, but doesn't allow to add forgotten variables. Didn't test it too much though)
You don't need to clear the log. If you press the retry on the pipelines view and then go to the job detail, you get the form to supply vars plus the button to trigger the manual action
I don't want to retry the whole pipeline just an individual job to have a job that can be re-runnable multiple times so as to be able to supply the variables and different values each time I retry the job.
I would find this feature extremely helpful. This would allow me to run a delete-instance job several times with a different AWS Instance ID each time. Instead of having to push the entire pipeline again.
I personally found no workaround the issue at hand. I hope it can be implemented soon.
In 14.x, this workaround no longer seems to work. The variable supplied in the dialog prior to clicking Trigger this manual action is ignored. See this video demonstration on Loom.
@jordan.dubie Thanks for the trick. I tried several times. But sadly it does not work. Gitlab shows you the component to enter new job parameters. But once you enter the parameters and click on "Trigger this manual action" then gitlab starts executing the pipeline without the user parameters you entered. Which means you can only run a job with parameters the first time only. Then you MUST push a new pipeline for it.
Steps to reproduce:
Create a gitlab-ci.yml file
Write a single MANUAL job that does nothing but outputting a variable called TEST_VARIABLE
Push your pipeline to Gitlab
Enter a value for the TEST_VARIABLE. Let's say "hello world"
Click "Trigger this manual action"
Watch how the variable is shown correctly this time
Hey guys!
Is this going to be as a feature some day? Because it's in backlog and seems like no once cares about it.
I opened the same issue not long time ago - #222525 (closed)
Yeah the manual jobs are carbage. Why can't the UI show accepted inputs for an example like Jenkins have done years ago? Any description or instructions for the user?
At the 1st time , I input wrong variable and job fail >> need to retry job.
At the 2nd time, I have to delete job log to show textbox insert key,value again >> fill with right key, value and trigger manual action again . But in log, job run without key,value in this job.
Why interested: the prospect (currently CE user) needs to customize deployments and uses manual jobs to pass variable representing these customization. The process breaks though when a need to re-run job occurs. This is seen as a bug impacting their standard workflow.
Current solution for this problem: restarting the pipeline entirely, which causes delays and end users dissatisfaction
Impact to the customer of not having this: significant increase in cycle time, manual operations
Questions: Can we prioritize this and schedule in the coming future milestones?
There are 2 problems to solve from what was originally reported in this issue:
Bug behavior where on retry of a manual job, the same variables previously specified are not being reused; for this I have created separate issue #327347 (closed).
Feature request to allow passing different variables when retrying a manual job; this will remain as the scope of THIS issue so I am relabeling this issue as feature.
Given CI's Q2-FY22 priorities, the bug issue will likely get prioritized soon while this feature issue will remain in the backlog for now.
Bump!
I would really want this too. We have some expensive pipelines in place and sometimes we just need to retry one job with different set of Variables.
What? support changing variables for jobs if manually (re)triggered Why? restarting the whole pipeline can be prohibitively expensive How? re-implement the 'retry bug' from above as working feature Bonus: until this issue is resolved, clarify this lack of support in the documentation
Journey
The last four hours or so I was reading the official documentation, searching the web, reading GitLab issues, asking friends, scratching my head... because I just wanted to have a simple way to debug a pipeline job like mentioned above #37268 (comment 468970237).
After a lot of confusion (especially in combination with prefilled variables not being shown) by the documentation and experiments (e.g. the workaround which isn't one #37268 (comment 322320646)) I ended up here, finally getting an answer to my journey: GitLab doesn't support it.
Not what I was hoping for but at least I can stop feeling stupid for being unable to implement what I wanted.
Why do I have to create duplicate jobs like foobar and debug_foobar to change variables, make jobs dynamically retrieve values from outside, retrigger the whole pipeline or run multiple pipelines simultaneously? (Retrying a specific stage seems to be unsupported, too?).
If job 69 in stage 42 fails and the pipeline took 2 life times, 3 kidneys and 4 legs to reach that point, restarting from scratch is not a viable option. Furthermore there can be cases where a bug can not be reproduced with certainty due to side effects from the rest of the pipeline, thus eliminating the chance to analyze what exactly happened. Always running on full verbosity and debug levels isn't best practice. 1
IMHO this is a very valid use case, hence supported by other platforms and GitLab is missing a major feature here, which can be a possible deal breaker for some.
If your pipeline ever reaches that point, please refactor it for your own sanity.
There is a Premium customer who is interested in being able to specify variables when retrying a manual job. GitLab team members with access to Zendesk can learn more in the ticket.
We are also looking at the related #32712 (closed) issue which has more activity and more recent activity.
This would also be useful for the Engineering Productivity team therefore adding internal customer.
Summary
During development of new policies for gitlab-org/quality/triage-ops we often execute dry runs from the Merge Request, which is a manual job where variables must be specified. Being able to tweak these variables upon failure of the dry run would be super useful
We are currently on Gitlab premium license. This feature is indeed a critical feature for us too. Instead of rerunning the entire pipeline that took 1 hours for 10 stages. We would only want to rerun one of the job with different values to get the report. This feature should be a high priority in my opinion.
Hi @f_caplette - I'm reviewing frontend candidates in &8209 for %15.4 without blockers and based on the work done in gitlab-foss#24935 (closed) which was fixed before, it seems that there is just frontend work here too with backend work. Can you confirm if that is the case so I can update labeling? Thank you!
Why interested: They want to use the product more efficiently.
Current solution for this problem:: re-run the entire pipeline when a job fails.
Impact on the customer of not having this: It this delaying deliveries especially when working with protected environments where authorization needs to be granted for specific users.
Hi @dhershkovitch, the customer in question has recently acquired another company that uses our competitor's solution, where this feature is available. This is critical to be able to transition these accounts to GitLab. Do you have any timeline for this feature to land in GitLab?