GitLab Helm Chart Generated `gitlab-migrations-1` job fails to start on upgrades with ArgoCD
Summary
Our company uses a GitOps workflow to update GitLab. Upon first installation of GitLab (using files created by helm template
and ultimately merged into main
), we've no issues whatsoever.
However when we attempt to upgrade this instance, a second job is unable to be created because one already exists by the name of gitlab-migrations-1
even though this job sits around with status "completed". It's not until I foreground delete
this gitlab-migrations-1
job can the new copy of gitlab-migrations-1
be created, and then all the other components are able to navigate their way back to healthy & upgraded successfully.
Steps to reproduce
- Leverage ArgoCD to deploy the k8s yaml rendered by
helm template
- Deploy GitLab using this GitOps flow.
- Attempt to upgrade using this GitOps flow. The upgrade will hang on any components that were modified between versions, as they will be waiting on the
gitlab-migrations-1
job to complete.
Configuration used
<REDACTED>
Current behavior
Synchronizations hang indefinitely on gitlab-migrations-1
.
Expected behavior
Ideally, the gitlab-migrations-1
job should have killed itself after it completed successfully, so a new upgrade could be dropped in there immediately. I'm not sure what the right solution is. A coworker of mine suggested a helm hook.
Versions
- Chart:
5.5.0
- GitLab version:
14.5.0
- Platform:
- Self-hosted: KOPS
- Kubernetes:
- Client:
1.22.3
- Server: <
redacted
>
- Client: