Improve error message when there's a conflict between `pull_policy` and `allowed_pull_policies` settings
What does this MR do?
This MR adds the pull_policy
configuration source (.gitlab-ci.yaml
, config.toml
, or a default
) to the error shown when there is a conflict between the pull_policy
and allowed_pull_policies
. It also adds to the error message the name of the image being pulled. The error messages now read like so:
"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in config.toml "
"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in gitlab-ci.yaml "
"failed to pull image 'alpine': conflict in allowed_pull_policies ([if-not-present]) and pull_policy ([always]) configured by/in default"
Why was this MR needed?
#29115 (closed) asks for the error message shown when there is a conflict between the pull_policy
and allowed_pull_policies
to specify the source of the offending configuration (i.e. in which file the offending configuration is made). allowed_pull_policies
can only be configured in the runner's config.toml
(for now?), but pull_policy
can be configured either in the project's .gitlab-ci.yaml
or the runner's config.toml
, OR a default value will take effect if it was not configured. Knowing this will make it easier for users to debug/fix pipeline errors related to pulling docker images.
I've also augmented the error with the image name because this configuration conflict can also affect gitlab helper images (e.g. registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper), which ONLY use the pull_policy
from confg.toml
. Not mentioning the image in the final error could lead to all manner of confusion, like "why isn't the pull_policy
in gitlab-ci
being propagated to the runner?" Including the image name in the error message will hopefully avoid that.
What's the best way to test this MR?
- register a runner with a
docker
orkubernetes
executor - configure the project's
pull_policy
(i.e. gitlab-ci) and the runner'sallowed_pull_policies
(i.e. config.tml) in an incompatible way - trigger a pipeline run
- watch the runner's logs to see the expected error message, OR just wait for the job to fail and the failure to appear on the pipeline run report. in this case the error should mention that the
pull_policy
configuration was made in the project's.gitlab-ci.yaml
.
Repeat 2-4 but with the following gonfigurations:
-
pull_policy
configured in both the project and runner -> error message should mention project config file -
pull_policy
configured in runner only -> error message should mention runner config file -
pull_policy
not configured anywhere -> error message should mentiondefault
What are the relevant issue numbers?
Notes:
- This MR is best reviewed commit at a time; it'll be much easier to digest read that way.
-
This MR is built atop !3504 (merged) since the latter contains changes that touch the same bits of code that this MR does, and merge conflicts will result when the latter is merged and the former rebased. Once !3504 (merged) is merged, I'll rebase this branch. So, DO NOT review the commits in !3504 (merged). Start at!3504 (merged) has been merged and this branch/MR rebased against[docker] Changes made automatically by gopls
.main
. -
This MR only addresses #29115 (closed) for thedocker
executor. Analogous changes will be required for thekubernetes
executor. I can/will make those changes is this same MR, or in a new one, but I though I'd at least get a review on the work so far in case it's going in the wrong direction.kubernetes
executor handling added.