feat: add runners_pull_policies to support multiple pull policies

[gmeligio]

Description

Support multiple Docker pull policies. The pull_policy parameter allows to specify a list of pull policies. The policies in the list will be attempted in order from left to right until a pull attempt is successful, or the list is exhausted.

https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work

Migrations required

NO - A deprecation notice was added to description. In a future release the variable runners_pull_policy could be removed in favor of runners_pull_policies.

Verification

I have verified the examples (https://github.com/gmeligio/terraform-aws-gitlab-runner/actions/runs/3040828783):

• Verify examples (1.0.11, runner-default)
• Verify examples (1.0.11, runner-docker)
• Verify examples (1.0.11, runner-multi-region)
• Verify examples (1.0.11, runner-pre-registered)
• Verify examples (1.0.11, runner-public)
• Verify examples (latest, runner-default)
• Verify examples (latest, runner-docker)
• Verify examples (latest, runner-multi-region)
• Verify examples (latest, runner-pre-registered)
• Verify examples (latest, runner-public)

[npalm]

PR looks good, but test results in runner is not started. Rebased the PR also against develop. Nu clue what the issue is right now. Not more time to dig in further. Got the following error:

Failed to restart gitlab-runner.service: Unit not found.

[npalm]

Just went over the PR again, made some small suggestion which fixed the non starting agent.

• used allowed_pull_policies
• set default for old pull_policy to empty, so by default new one is used.

[npalm]

Accepted my suggestions, tested and all good. Thanks for your contribution

[semantic-releaser]

🎉 This PR is included in version 5.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[cinacio]

Just went over the PR again, made some small suggestion which fixed the non starting agent.

* used `allowed_pull_policies`

* set default for old pull_policy to empty, so by default new one is used.

First of all, thanks a lot for all the hard work on this module that makes our lives much easier!

I'm wondering about this change and the above suggestions. It's quite nice that we can now specify allowed pull policies, but if I read the docs correctly this slightly changes the behaviour of the modified directives and now prevents us from specifying a "default" pull policy for runners.

Setting allowed_pull_policies will define the policies that can be used in the .gitlab-ci.yml file or the runner configuration, but keeping pull_policy unset will keep it at its default value, which is always according to the GitLab runner advanced configuration documentation. Thus preventing us from modifying the "default" pull policy at the runner level, and forcing image downloads unless the policy is explicitly set in job configurations. Or am I missing something?

Wouldn't it be better to have two different directives, actually?

[gmeligio]

Thank you @npalm for reviewing and fixing the PR. I like that you added allowed_pull_policies but the merge looks slightly different from the original idea of allowing fallback policies.

allowed_pull_policies only whitelist the wanted values but doesn't add fallback policies in case of failure, whilst pull_policy array adds that fallback. Maybe I didn't explain it clearly in the PR description. According to Gitlab docs:
You can set it to a single value or a list of pull policies, which will be attempted in order until an image is pulled successfully.

I agree with @cinacio that using allowed_pull_policies prevents the default behaviour and could be confusing if we pass no value for allowed_pull_policies. As he mentioned, it could be good to have both directives.

If it's OK, I can create two PRs: one to restore the default behaviour of allowed_pull_policies and the other to support pull_policy (single or multiple)

[npalm]

I think I was a bit in a hurry to got all the too long open PRs merged. Thank you for pointing this out. Please go ahead make two PRs. That would be very welcome!

[kayman-mk]

Also see #511

[cinacio]

@npalm As I figured @gmeligio might be busy elsewhere, I took the liberty of creating PR #557 just to set pull_policy instead of allowed_pull_policies.

I hope that's alright.