Skip to content

Add logic to create ci_runner_machine based on system_id param

Pedro Pombeiro (OOO from July 16th till Aug 7th) requested to merge pedropombeiro/387181/2-create-ci_runner_machines into master

MR chain breakdown:

Sequence MR
1 Add runner_machines relationships (!109980 - merged)
👉 2 Add logic to create ci_runner_machine based on ... (!109983 - merged)
3 Implement Ci::RunnerMachine#heartbeat (!109985 - merged)

Part of Use runner token + `system_id` JSON parameters ... (#387181 - closed)

What does this MR do and why?

Describe in detail what your merge request does and why.

This MR adds logic to accept the system_id optional param on the POST /jobs/request endpoint, and create the corresponding ci_runner_machine if needed. The POST /jobs/request endpoint is internal and undocumented, meant to allow the GitLab Runner to poll for jobs.

This MR follows the Runner Token Architecture blueprint.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

How to set up and validate locally

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

  1. Ensure that you have a runner registered against your local GDK;

  2. On the GDK console, look that runner up and confirm that it has no runner_machines associated. Let's assume that the runner has id 1:

    > Ci::Runner.find(1).runner_machines
=> []

  3. Make sure that gitlab-runner is running and polling for jobs for that runner;

  4. Go back to the GDK console and notice that the runner now has runner_machines associated.

MR acceptance checklist

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

Edited by Pedro Pombeiro (OOO from July 16th till Aug 7th)

Merge request reports