This MR inject the step-runner binary into any user-specified build image, for the docker executor only.

The MR starts with a bunch of mostly minor refactoring to make room for a third container type (build and predefined, plus a new step-runner container type). From there it adds a method to create a new shared volume into which the step-runner binary will be coined, and from which the step-runner will be run in the build container. It also adds methods to pull and run the step-runner container, and finally hooks it all up to actually run the step-runner container.

Notes:

Re: the path at which the new volume is mounted in the build container, I originally planned to mount the binary at /usr/bin/step-runner so I would not have to modify the container's PATH. Unfortunately AFAICT it is not possible to mount a file (vs a dir) using the docker APIs (it is possible at the command line). In addition, While assuming /usr/bin is in PATH is safe, there's no actual guarantee that it is the case. For those reasons I mounted the shared volume at /opt/step-runner since it's unlikely to conflict with anything else. The volume mount point on the step-runner container doesn't really matter.
Re: The step-runner image name and version, there are sane defaults (registry.gitlab.come/gitlab-org/step-runner and the version of the step-runner library against which the runner binary as compiled), but both can be specified via the variables STEP_RUNNER_IMAGE and STEP_RUNNER_VERSION.
To keep things simple, I've decided to tie running the step-runner container to the helper container since things currently done by the helper container will eventually be done via steps. Note that the helper container is "run" multiple times; once each to do things like cloning the project, downloading the cache, downloading artifacts. A consequence of tying the step-runner container execution to the helper container execution is that the step-runner container will be run multiple times. While slightly wasteful, this is OK because with step-runner!170 (merged) (merged) the bootstrap command is idempotent.
Re: integration test, I've used fedora:latest because there are (different) issues with alpine and debian/ubuntu based images that are outside the scope of this MR. I've also used a registry.gitlab.com/gitlab-org/step-runner/pipeline:982 version of the step-runner image to make sure I'm using the change in https://gitlab.come/gitlab-org/step-runner/-/merge_requests/170. I'll remove this when we make a 0.4.0 release of step-runner.

Best reviewed commit-at-a-time.

Testing

Build and run a runner from this MR's branch using this (or any) config (there are no runner config additions here).

[[runners]]
  name = "foo"
  url = "https://gitlab.com/"
  id = 0
  token = "FOO"
  executor = "docker"
  # optional
  # step_runner_image = "foo:bar" 
  [runners.docker]
	pull_policy = ["always"]

Run this job.

stages:
  - test

variables:
  FF_USE_NATIVE_STEPS: true

script step fedora:
  stage: test
  image:
    name: fedora:latest
  run:
    - name: step1
      script: dnf install -y go
    - name: step2
      script: go version
    - name: step3
      script: ls -Rlah ../

Closes Copy step-runner binary to job Docker container (step-runner#149 - closed)

Edited Feb 06, 2025 by Axel von Bertoldi

Inject the step-runner binary into the build container [docker executor]

Testing

Merge request reports