Add further differentiation between token types (Breaking Change)

• Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA

BREAKING CHANGE

What does this MR do?

This MR resolves the missing logic regarding the token mounts with byo secrets. It adds a new object for runners.secret (before is was just a secret name), which contains 3 new values:

• useExistingSecret - this dedicated toggle makes absolutely obvious what was done before by checking the content of the values for runnerRegistrationToken and runnerToken. When setting this flag to true, no custom secret will be created and the deployment will reference the secret ..
• name - .. with the name, provided via this value. If this value is not set, if will fallback the default as before.
• hasAuthToken - this flag helps to clarify, what kind of token is used and given via the secret. It assumes, as the now new default, that a runnerToken is given (therefore assumes key and path in the secret projection runner-token). If explicitly set to false (therefore a runnerRegistrationToken is in the secret), it will try to mount the secret using runner-registration-token as key and path.

In case of useExistingSecret: false, the Chart will create a secret as before. In that case, to avoid further confusion and reduce redundancy in the rendered templates, now only runner-token OR runner-registration-token are added as keys to the secret, depending on which one was given. If both are set, the runner-token has higher precedence and the runner-registration-token will be ignored.

To help users migrating from before, I added two warnings in the Notes, when a invalid or at least unneeded combination of values is passed.

Why was this MR needed?

This MR resolves the issue described in #527. When using the new, now default option to create and register runners (runnerToken) while using the byo secret option, one needs to add both keys to the secret - runner-token and runner-registration-token. Also, when using the secret creation mechanism, both keys were added to the new secret, which might be confusing for the users.

What's the best way to test this MR?

Best way to test this MR is checking my introduced tests for completeness and / or render the following three value sets manually:

1. New default: use default values. Expectation: Chart creates a new secret with the runner-token key. This secret will be mounted / projected in the deployment and as well reference the runner-token.

2. pass registration token: set runnerRegistrationToken: my-new-token. Expectation: Chart creates secret, using runner-registration-token as the key in secret and secret mount.

3. use existing secret with runner token: set runners.secret.useExistingSecret: true runners.secret.name: my-secret. Expectation: Chart does not create a secret. Deployment references the secret with the name my-secret using runner-token as key and path.

4. use existing secret with registration token: set runners.secret.useExistingSecret: true runners.secret.name: my-secret runners.secret.hasAuthToken: false. Expectation: Chart does not create a secret. Deployment references the secret with the name my-secret using runner-registration-token as key and path.

What are the relevant issue numbers?

Resolves #527

Additional Information

previously, there was some custom logic to recognize a authToken when passen with registrationToken (prefix: glrt- - i'm not sure if this is still needed, as this was only a precious action to avoid breaking changes. As this MR introduces a Breaking Change (therefore leading to a major chart update), this could be dropped.