Update cluster management project template
What does this MR do?
Updates the cluster management project template with the latest version.
Makes the GitLab Runner install support tokens through
CI/CD vars. CI_SERVER_URL
and GITLAB_RUNNER_REGISTRATION_TOKEN
.
Manual QA
New variables are available after creating a project from the new template in GDK
Job successfully install the Runner
https://gitlab.com/Alexand/test-cmp-with-runner-vars/-/jobs/1506962848
The associated project recognized the new specific runner
How to setup and validate locally (strongly suggested)
Even though it might be possible to test all in GDK. It might require to setup K3s locally which might be a bit more work. The easiest way is to just validate that on GDK the Runner values in the template contain the CI env vars, then use a project on .com to validate that the new template actually installs the Runner properly with the correct env variables. Since on GitLab.com the template won't be yet embedded, one can clone it from https://gitlab.com/gitlab-org/project-templates/cluster-management instead. So:
On GDK
This assures the template has been updated:
- Create a new project from a template using the cluster management template.
- Verify that the new
applications/gitlab-runner/values.yaml.gotmpl
exists with the new env varsCI_SERVER_URL
andGITLAB_RUNNER_REGISTRATION_TOKEN
.
GitLab.com
This assures that the template works with those vars for installing your Runner.
- Create any project (A) on GitLab.com
- Add a cluster to project A.
- Create another project (B), this time by cloning or importing the latest template.
- Make project B the cluster management project of cluster A. Just follow the linked section, no need to do the rest of what the docs indicate.
- From project A, go to "Settings" -> "CI/CD", expand the runners section and copy the token necessary to create your project level GitLab runner.
- On project B go to "Settings" -> "CI/CD", expand the variables section and add a masked and protected variable named
GITLAB_RUNNER_REGISTRATION_TOKEN
. The value should be the token taken from project A. - On project B update the
helmfile.yaml
present in the root folder by uncommenting- path: applications/gitlab-runner/helmfile.yaml
. Remember to keep 2 spaces of indentation. - After the pipeline for project B succeeds, go back to the project A on "Settings" -> "CI/CD", runner section. The new runner should be available for your project.
Does this MR meet the acceptance criteria?
Conformity
-
I have included changelog trailers, or none are needed. (Does this MR need a changelog?) -
I have added/updated documentation, or it's not needed. (Is documentation required?) -
I have properly separated EE content from FOSS, or this MR is FOSS only. (Where should EE code go?) -
I have added information for database reviewers in the MR description, or it's not needed. (Does this MR have database related changes?) -
I have self-reviewed this MR per code review guidelines. -
This MR does not harm performance, or I have asked a reviewer to help assess the performance impact. (Merge request performance guidelines) -
I have followed the style guides. -
This change is backwards compatible across updates, or this does not apply.
Availability and Testing
-
I have added/updated tests following the Testing Guide, or it's not needed. (Consider all test levels. See the Test Planning Process.) -
I have tested this MR in all supported browsers, or it's not needed. -
I have informed the Infrastructure department of a default or new setting change per definition of done, or it's not needed.
Security
Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team