Skip to content

Update autoscaler image handling

Tomasz Maczukin requested to merge update-autoscaler-image-handling into main

What does this MR do?

Improves slightly how the new Instance executor handles image usage (when VM isolation through nesting is enabled).

Why was this MR needed?

Technically, these improvements will handle three kinds of problems:

  1. Not clear failure when image is not defined neither in the job (through the image: keyword) nor in the Runner configuration (through the image setting under [runner.autoscaler.vm_isolation]. Currently if none of these are defined we will get an error coming from nesting. With the change added in this MR we will get a clear error, similar to the one we have in Docker executor where a similar problem may be triggered.

  2. Invalid allowed_images usage when user don't specify image on the job level. In that case the Runner level configuration should be enforced (and we should instruct the runner owner that this setting is required - just like we do with Docker executor). In that case there is no need to validate the image and in fact, validation would fail as in https://gitlab.com/gitlab-org/ci-cd/tests/saas-runners-tests/macos-platform/saas-macos-staging-basic-test/-/jobs/4308986201 because an empty image value (read: not defined in .gitlab-ci.yml) will definitely not match any of the images defined in allowed_images.

  3. Allowing to define the image to use in a more elastic way, by using a variable. This will fix a problem like in https://gitlab.com/gitlab-org/ci-cd/tests/saas-runners-tests/macos-platform/saas-macos-staging-basic-test/-/jobs/4308986204.

    There may be a valid case, where the image: definition will use a variable. We see that in Docker and Kubernetes executors, where it's set for example as:

    job:
      image: docker:${DOCKER_VERSION}-git
      (...)

    For the Instance executor users may also want to provide part or whole image name with a variable.

These three changes will improve the usage of Instance executor and in scope of the image: keyword usage will align the behavior of Instance executor with Docker, Docker Machine and Kubernetes executors.

What's the best way to test this MR?

What are the relevant issue numbers?

Edited by Tomasz Maczukin

Merge request reports