Test config validations
These charts have some config validations in https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/templates/_checkConfig.tpl, and also some elsewhere (for instance, a required
in https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v3.0.6/charts/certmanager-issuer/templates/_issuer.yaml#L14).
Failures in these will halt and print to standard error. To tweak the example from #1984 (closed), this config:
certmanager-issuer:
email: test@example.com
gitlab:
sidekiq:
pods:
- name: invalid-1
queues: [merge]
negateQueues: [post_receive]
- name: invalid-2
queues: [merge]
negateQueues: [post_receive]
Fails with this error:
$ helm install --dry-run gitlab . -f fail.yml
Error: template: gitlab/templates/NOTES.txt:46:3: executing "gitlab/templates/NOTES.txt" at <include "gitlab.checkConfig" .>: error calling include: template: gitlab/templates/_checkConfig.tpl:39:54: executing "gitlab.checkConfig" at <fail>: error calling fail:
CONFIGURATION CHECKS:
sidekiq: mixed queues
It appears you've supplied both `queues` and `negateQueues` for the
pod definition of `invalid-1`. `negateQueues` is not usable if
`queues` is provided. Please use only one.sidekiq: mixed queues
It appears you've supplied both `queues` and `negateQueues` for the
pod definition of `invalid-2`. `negateQueues` is not usable if
`queues` is provided. Please use only one.
$ echo $?
1
It should be possible to check this in our CI pipeline, and locally. We could provide:
- A list of Yaml files.
- Expected output to standard error (if the config should fail), or a flag that it should pass. If output is expected to stderr, we should ignore the first line as it contains line numbers which can change without any change in behaviour.
We could then run these through a simple command like the above and check the exit code and standard error output match what we expect.
As we already have RSpec, we could quite easily use that, or use a simple script that just looks through a directory for matching input and expected output.