Register omnibus runners on the docker executor so flows run

Andrew Dunnrequested to merge
fix/omnibus-runner-flows into main

MR description draft (gitlab-com/public-sector/gitlab-simulation)

Title: Register omnibus runners on the docker executor so flows run

Flows now run on the omnibus base. Its runners register a docker executor over the VM's podman socket, the executor caproni already uses, because GitLab documents the shell executor as unsupported for flows (Configure runners to execute flows).

Closes #10 (closed)

flowchart LR
    R["register_runner<br/>on omnibus"] --> S["--executor shell<br/>(before)"]
    R --> D["--executor docker over<br/>/run/podman/podman.sock<br/>(after)"]
    S --> H["job runs on the VM as gitlab-runner<br/>and ignores its image"]
    H --> X["cli_install_commands writes /usr/local/bin/duo<br/>curl: (23), no checkpoint"]
    D --> I["job runs in workflow-generic-image<br/>which already ships duo"]
    I --> W["duo run over a websocket<br/>to GITLAB_BASE_URL"]
    W --> C["workflow checkpoints"]
  • duo-runner-register and ci-runner-register register the same executor on omnibus as on caproni: --executor docker over the rootful podman socket, privileged as the flows page asks for the sandbox. The general-purpose runner changes with it, since SAST also asks for a Docker or Kubernetes executor.
  • The omnibus runner registers at the instance's external URL. A job container's 127.0.0.1 is the container, and the job is handed the external URL as GITLAB_BASE_URL in any case.
  • gce.md, seeding.md, airgap.md and SKILL.md stop describing a shell runner on omnibus, and the validation matrix marks omnibus flow execution from this lab.
  • The engine self-test pins the executor and URL on each base, and fails against the previous register_runner.

What the lab showed

One omnibus instance on GitLab 19.4.1-ee with a staging license and the mock model, on the default lane unless a row says otherwise, torn down afterwards. With the runner main registers, simulation/test failed before its first checkpoint, the limit !31 (merged) recorded. With this branch's runner the same flow, started the same way, finished with 5 checkpoints.

The checks
behaviour result
flow on main's shell runner failed with 0 checkpoints: curl: (23) writing /usr/local/bin/duo, which the gitlab-runner user cannot write
flow on this branch's runner finished with 5 checkpoints; the job ran in workflow-generic-image:v0.0.15, found duo already installed, passed the sandbox test, and opened its websocket to the instance's external URL
the same flow on the development lane finished with 5 checkpoints
general-purpose runner an untagged job ran in alpine:latest and uploaded its artifact
just doctor no drift

Known limits

  • A sealed omnibus now needs the job image and the runner helper image inside the boundary, and the job is handed the instance's external URL, which the seal's allow rule does not cover. Neither a flow nor a CI job under seal on omnibus has run.
  • runner-docker-auth applies on omnibus now, against a registry named explicitly (omnibus serves none). It has not run there.

Testing

just ci passes, the engine self-test included. Lab evidence is above.

Claude Code assisted with the change, its tests and this description, and ran the lab checks above. Each commit carries the AI-Assisted: yes and AI-Tools: Claude Code trailers that CONTRIBUTING.md asks for.

Merge request reports