Design: Surface the used custom variables for manual jobs and allow to retry the job with updated variables

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Release notes

Problem

When running a manual job from the manual job page, it's possible to add custom variables for that job.

Right now it's not possible to view or override the variables being used when retrying the job. Developers want to be able to tweak variables used by a manual job when working on a deployment, for example. Sometimes you need to go back and tweak the input.

Intended users

• Devon (DevOps Engineer)
• Sasha (Software Developer)

Metrics

• Click rate on the Variables tab
• Number of users retrying manual jobs with updated variables vs. retrying with the existing variables

User experience goal

The user should be able to view the custom variables used by a manual job, update them if necessary, and retry the manual with with updated variables.

MVC Proposal

• For manual jobs, add offer two "Retry" action types: "retry" and "update variables".
• The "retry" action remains unchanged, it retries the job with the same variables.
• The "update variables" action opens the manual job page with the variables form where the used variables can be viewed and updated.

For the detailed description of the user flows see the designs.

SPECS IN FIGMA

DESIGNS

Permissions and Security

User can only view the variable and value in the manual job if they have the permissions to view those variables based on their role in the project.

Documentation

This feature needs to be documented in the Variables and manual jobs documentation.

Availability & Testing

Available Tier

• Free

Further iterations

• Surface all available variables for that job (not only custom variables)
• Add the variables form to all jobs (not only manual jobs)
• Improve the form input to include filtered search to make it easy to select available variables
• Surface the project level variables that are being inherited by the job, and indicate when they're being overridden by the custom variables. Those can be view-only since they're set on project level, but it can be useful to see them for the context.
• There can be further improvements to the variables form, for example when a variables has "true" or "false" values we can automatically offer those options in the dropdown.
• Offer possible variable values to choose from a given variable

Implementation Table

Group	Issue Link
UX Design	You are here
backend	#361236 (closed)
frontend	#361237 (closed)

mentioned in issue #32731 (closed)

mentioned in issue #32800 (closed)

mentioned in issue #32875 (closed)

added Category:Continuous Integration devopsverify grouppipeline execution typefeature labels

mentioned in issue #32985 (closed)

mentioned in issue #33512 (closed)

mentioned in issue #33969 (closed)

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

Also: noticed on 12.2.0, if you run a job with a custom variable defined via the UI, retrying the job will not re-use the initially defined variable.

1. Would be great to have visibility, on the UI, what special variables were used for a given job;
2. If we re-run, have the possibility to re-use the same variable, or change it.

Right now, the only way to do this is to manual trigger the whole pipeline again by use Run Pipeline.

However, if your pipeline run super long, or the build is not idempotent, there will be a problem.

It is super helpful if Gitlab can allow trigger manual job more than once.

I was going to request this, but not only for manual jobs. I want to be able to retry any job with custom variables.

+1 on this feature request. This is the behaviour I expected when re-triggering manual jobs.

I tried to hack around it by erasing the job log so I'm presented with the input prompt again (success!) but clicking "Retry this job" doesn't respect my input.

Any ideas when this can be implemented?
I am part of customer team, really looking forward on this feature presence.

Listed as important to a commercial customer: https://gitlab.my.salesforce.com/0016100000fyUv5 (Internal)

added customer label

This is a problem for us in Quality too. As others have noted, it's worse than the initial description - we can't even rerun the job with the same variables.

We sometimes need to be able to run a specific set of tests in CI that's different from the various statically configured sets, and we can do so using the custom variables feature (e.g., gitlab-qa!362 (merged))

However, one key use case for us is to be able to repeatedly run the same quarantined test to verify that it's not flaky. Unfortunately, we can't do so yet because retrying ignores the custom variables.

Here is an example:

• Using custom variables specified here: b393fa0c (comment 269433152)
• First run with custom variable (running only 4 tests): https://gitlab.com/gitlab-org/gitlab-qa/-/jobs/397646533
• Second run that ignored the custom variables: https://gitlab.com/gitlab-org/gitlab-qa/-/jobs/397711554 (cancelled because it was running all the tests, instead of the 4 specified)

/cc @jyavorska

@mlapierre - @thaoyeager is the PM for this area, so looping her in to consider scheduling. Thanks for the ping!

added internal customer label

mentioned in issue #31367

marked this issue as related to #31367

mentioned in merge request gitlab-qa!362 (merged)

mentioned in commit gitlab-qa@2b5a7038

mentioned in merge request gitlab-qa!369 (merged)

Came across this today. I made a mistake declaring a variable for a manual action in the pipeline. It was not possible to retry the same job and fix the mistake without creating a new pipeline

@jyavorska I'm adding the direction label but will leave to you for best milestone to target.

added direction label

Possible duplicate with #37268 (closed)? Also, as mentioned there, there is a (sort of) workaround with re-running the pipeline (not triggering another pipeline, as this reruns all previous steps as mentioned above). Also, workaround mentioned here (erasing the log and providing variables) does not always work for me. I suspect that it only allows overwriting variables passed to the previous run, doesn't allow overriding / adding new variables.

@pplorange it's not a valid workaround for us.

mentioned in issue #207988 (closed)

My customer would like to create automation that says get last deploy to 'blue' environment for each project. now deploy the exact same thing to the 'green' environment In order to do this, they want to leverage the same job but pass {"variables": {"ENVIRONMENT_NAME": "green"}} to https://docs.gitlab.com/ee/api/jobs.html#retry-a-job.

Please read use case within the Customer Success Project.

mentioned in merge request !22374 (merged)

mentioned in commit gitlab-qa@e713d75c

We would also like this to be fixed, since after the first trigger of the manual job with custom input variables, in order to be able to re run it, you have to manually trigger the whole pipeline (if you do not want to push something else)

Another premium customer wanting this feature https://gitlab.my.salesforce.com/0016100000NmU19 (internal link)

We think this would be a very useful feature within enterprises where job overrides/re-trigger (with manual variables) are needed for a certain process evaluation or elevated privilege based on deploy environment and who can deploy to those environments.

This context is provided via a principal engineer at a 5,000 seat .COM customer.

@thaoyeager for vis :)

added needs weight label

mentioned in issue #212901 (closed)

added UX backend frontend labels

This requires additional Product Management and UX work before we can do a frontend / backend technical assessment.

FYI @kencjohnston @thaoyeager @dcipoletti @darbyfrey @dimitrieh

@kencjohnston @thaoyeager @dimitrieh WDYT about the following:

When clicking on Retry for a manual job the user is directed to a page where they can specify the variables again (which are pre-filled with existing variables)? I think this might need to be a new page, but we could re-use the existing variable UI.

---

The alternative is to copy the initially defined variables and re-run the job with those, but that does not fascilitate the use case described in the comments here.

@dimitrieh - Since I'm sub-ing in and lack context. Could you propose a design here? Is this something that requires solution validation? I think it is clear that we have a validated problem here.

set weight to 3

set weight to 4

I'll weight this a 4 to be conservative, until we define a more concrete proposal. It'll most likely be a 3 once we get to the actual implementation.

added needs investigation label and removed needs weight label

added workflowscheduling label

We have a manual job which relies on multiple variables which have to be manually entered before pressing play. If the job fails due to any reason (Runner failure, script failure, timeout) or you simply made an error when entering the variables, you have zero chance to retry the job.

Editing retry would be great! Can maybe mimic how Jenkins does it - they allow you to replay a job, and modify the Jenkinsfile (without modifying the original source)

https://www.jenkins.io/doc/book/pipeline/development/#replay

added 1 deleted label

Is there any hope for progress here?

We really need this feature

Customer https://gitlab.my.salesforce.com/00161000019dARj would like to see this feature. Firing off a manual job with one or more variables specified manually prevents you from firing off the same job in the same pipeline again with different variables/values. One currently has to create a new pipeline from the same commit and then run the manual job there. This is annoying when the manual job you want to run is preceded by several other dependent tasks.

added sectionops label

added workflowready for development label and removed workflowscheduling label

This is the main feature keepings us on Jenkins and not fully moving to Gitlab. If Gitlab had better parametrized runs and retries, would be perfect!

+1 for this feature -- fat fingering is real, and without the ability to change variables...end up having to go to the beginning of a long pipeline.

+1 - this is an absolute must. We're trying to use failsafes on manual jobs we don't want to accidentally run, such as rolling back deployments etc. Our CI pipeline checks to make sure that ROLLBACK is set to the project name, but if someone forgets to do this, or there is a typo in the name, we can no longer trigger this manual job...

Is this feature prioritized at all?

We are waiting too for such an important feature

Has anyone from Gitlab acknowledged this issue?

@thaoyeager for visibility

@yofeldstein

@thaoyeager a similar issue has been reported by a 2,000 seat customer: https://gitlab.my.salesforce.com/001610000111pVc. The customer is interested in this feature.

We (as another commercial customer) would like to join to the requestors. When running a manually triggered job (when: manual) users can provide additional variable just for that job when triggering it in the web interface. We want to be able to re-try such jobs, though with change/different variables (names and values). This should ideally work when retrying failed as well as succeeded jobs that have "when: manual"

Customer record here for reference.

@thaoyeager is there a way to get this picked up? I see from #32712 (comment 325762638) that this was previously discussed but not prioritised.

This would be a very helpful feature for the Delivery team, we have many situations where we need to retry failures with CI variables set to override conditions, and right now it usually means we need to set a CI variable and manually remove it once the job starts.

Customer interested by this feature:

• https://gitlab.zendesk.com/agent/tickets/181860 (internal)
• https://gitlab.my.salesforce.com/0016100000UsZzSAAV (internal)

Is there work on this feature planned? I think that would be needed for us to be able to switch from jenkins to GitLab

mentioned in issue gitlab-com/gl-infra/delivery#1425 (closed)

+1 - Came across similar issue! We have trigger whole pipeline again and wait to trigger manual job id in case we have passed wrong variables! Is there already a fix for this ?

@awthomas could you help us get some traction on this?

@jreporter @thaoyeager wanted to bring this one to your attention. Would it be possible to prioritize in an upcoming iteration?

I will defer to @thaoyeager

@thaoyeager this seems to have several different sensing mechanism on it, 1) Paid demand, 2) Dogfooding demand, 3) Community interest.

Can you advise where this sits in your priorities?

+1 for this feature please. Could we have a schedule for this?

+1 for this. Having to run the whole pipeline again is horrible.

+1

This would be huge for us.

If you're subscribed to this thread, it might be worth adding a "I'm still here and I still want this" message so it gets traction.

I follow every message on here and sympathize with everyone. I wish I could do more.

How much do I want this? This is my #1 (closed) request. To see update after update go out with other features no one on my team will ever use while this one sits here without any timeline... hello?

I'm still here and I still want this

I'm still here and I still want this

I'm still here and I still want this

I'm still here and I still want this

I'm still here and I still want this

pon., 11 sty 2021 o 10:54 Yoann Moinet gitlab@mg.gitlab.com napisał(a):

I'm still here and I still want this

#metoo

I know this isn't another useful Kubernates-related feature, but I'm still here and I still want this.

mentioned in issue gitlab-com/gl-infra/delivery#1475

It would be a great feature and makes sense. Hope it gets implemented soon. I still want this.

While I can appreciate the potential UI difficulties, can we at least get two very basic aspects of this: (1) Visibly display, somewhere, the manual inputs to a job; and (2) Make "Retry" use any such inputs when retrying.

I'd love to get (3) Make any attempt to rerun any job or pipeline have an option to set or alter input variables. I add that last because, as noted above, there is no way to get back to the input variable page. I can only look at what it's already done and have the useless "Retry" button, which technically doesn't retry because it forgets those variables.

As a workaround until this feature comes in, you can trigger a pipeline via the rest API and provide variables there. It's not quite the same but it works.

https://docs.gitlab.com/ee/ci/triggers/