Backend: Specify variables when running a manual job via REST API
Release notes
Previously, when running a manual job it was only possible to specify variables through the UI, in this release we've added the ability to specify variables using REST API, which helps you speed up and automate your pipeline
Specify variables when running a manual job via REST API
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 there appear to be no such ability when using REST API.
Specifically:
- Jobs / Play a job documentation has no mention of it
- Trying to imitate frontend behavior does not help either:
-
Posting
{"job_variables_attributes":[{"key":"TEST_VAR","value":"value 2"}]}to https://HOSTED_GITLAB_URL/GROUP_NAME/PROJECT_NAME/-/jobs/JOB_ID/play results in following error:<head> <meta content="width=device-width, initial-scale=1, maximum-scale=1" name="viewport"> <title>The change you requested was rejected (422)</title> -
Posting
{"job_variables_attributes":[{"key":"TEST_VAR","value":"value 2"}]}to https://HOSTED_GITLAB_URL/api/v4/projects/PROJECT_ID/jobs/JOB_ID/play results in the job started with default parameters (request body ignored).
-
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 send additional information between different jobs/pipelines via manual triggers (e.g. one project pipeline could trigger another project pipeline and then asynchronously wait on the dependent pipeline to trigger a callback job in current pipeline).
- Allow to retry failed manual job with different parameters in the absence of UI support for the same.
Proposal
Currently, we use job_variables_attributes: { key: 'my_var', secret_value: 'my_value' }. We can use the same structure in our API.
Permissions and Security
Existing permissions for running manual jobs seem to be applicable here as well
Documentation
Testing
What does success look like, and how can we measure that?
Given a pipeline with a manual job (in any status) exists, when a user with necessary permissions to run the job in the given pipeline sends a POST request to the Play a job REST API with additional jobs variables values, then the job is (re-)started with the specified variables values.
What is the type of buyer?
Core