Update autoscaler image handling
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:
-
Not clear failure when image is not defined neither in the job (through the
image:
keyword) nor in the Runner configuration (through theimage
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. -
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 inallowed_images
. -
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.