Define process to update our GitLab agent in our test clusters in every milestone
Summary
We faced a recent a recent problem in our pipelines because our GitLab agent was 14 versions late in 2 of our clusters. We need a process for updating our agent, as the recommendation is that the agent version should follow the GitLab version.
See: Agent updates and version compatibility
Related issue: #5316 (comment 1766899476)
Proposals for discussion
- Scheduled job that auto-updates our agent once per month.
- Manage versions in a Helm values file, and let dependency bots push an MR for updating.
Technical considerations
A scheduled pipeline could bump a major version without us being ready for it. An MR to bump a version is safer in that sense.
The update command needs to pass the existing agent token. It can either be:
- Taken from the existing secret, but we need to be careful to not expose it in our jobs.
- Stored in CI env vars, but this means managing on env var per cluster.
Questions
- Where is the EKS agent!?
Edited by João Alexandre Cunha