Skip to content

Add 'runner_opts' to jobs and services

Arran Walker requested to merge 385620-introduce-runner_opts-to-ci-jobs-and-service-definitions into master

What does this MR do and why?

Adds new runner_opts CI/CD keyword to jobs and services (issue #385620 (closed)).

GitLab doesn't validate this field, beyond checking that it is a Hash. The data will be passed to Runner as is, where it can be validated there.

The kind of values that will eventually be passed using runner_opts are values that we currently have to pass with job variables and specifically used to config the runner, executor and build environment.

Using job variables is fairly limited, as everything needs to be a string and the mix of concerns can be confusing and can occasionally break things.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

  1. Define a job with runner_opts:

    job:
  script:
    - echo "hello"
  runner_opts:
    a_bool: true
    a_string: "hi"
    a_hash:
      foo: "bar"
    an_array: [ "foo", "bar" ]
  services:
    - name: "docker:dind"
      runner_opts:
        a_bool: true
        a_string: "hi"
        a_hash:
          foo: "bar"
        an_array: [ "foo", "bar" ]

Runner doesn't yet support this feature, but requesting a job and inspecting the payload should expose runner_opts.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Closes #385620 (closed)

Merge request reports