Skip to content

Allow the --limit option to control the number of jobs a single runner will run

What does this MR do?

Implements two new features for the run-single executor:

  • Make the existing --limit option specify the maximum number of builds the runner will execute. The default of zero means run forever. Previously, it appeared this option did not do anything.
  • Adds a new --wait-timeout option that specifies how long a the runner will wait for jobs. The default of zero means wait forever

Why was this MR needed?

This MR introduces new functionality that is useful when you want to run the gitlab-runner on cluster resources managed by a DRM like LSF.
In these systems, you cannot have an executable running forever. Instead you submit jobs (executable) to run for a max-time.
With the new functionality of this MR, you can submit a job to run the gitlab-runner in run-single mode with --limit=1 --wait-timeout=600. If a job becomes available within 600 seconds, it will be built, and then the runner will exit, returning the machine resources back to the cluster.

Are there points in the code the reviewer needs to double check?

  • Understand the complexity build failure.
  • Understand the unit tests build failure.
  • This code has only been tested with the "shell" and "docker" executors. Will others have unforeseen issues?

Does this MR meet the acceptance criteria?

  • Documentation created/updated
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Branch has no merge conflicts with master (if you do - rebase it please)

What are the relevant issue numbers?

  • gitlab-org/gitlab-ci-multi-runner#1211

Merge request reports