The setup could make sense, if there’s a separate repo that’s pull only. Our ops guys pull our ArgoCD repo, so we can do the actually work, but they control what’s deployed on production.
Yes, but Gitlab doesn’t allow for easy access rules.
Basically, OPS wants full control of the repo, since they are the ones being blamed if something goes wrong. There’s no way to enforce, that only a certain set of users can make changes to a branch - all such restrictions can be circumvented rather easily.
So the solution is a shadow copy of the repo that only gets updated on release and Argo only deploys a specific tag (i.e. release).
We’re not talking about just some enterprise microservice, but stuff in the public administration/government sphere. The tradeoffs are a bit different there.
I didn’t know that GitLab doesn’t allow that! We use BitBucket and there it’s extremely easy to put branch restrictions so that only certain Usergroups are allowed to merge into the release-branches
I know that you are probably not the one who came up with this shit but just… why? Why would you do that?
Don’t you know that git has so called branches?
The setup could make sense, if there’s a separate repo that’s pull only. Our ops guys pull our ArgoCD repo, so we can do the actually work, but they control what’s deployed on production.
However, this seems not to be the case here.
But… also in ArgoCD you just set up which branch you want to look at
Yes, but Gitlab doesn’t allow for easy access rules.
Basically, OPS wants full control of the repo, since they are the ones being blamed if something goes wrong. There’s no way to enforce, that only a certain set of users can make changes to a branch - all such restrictions can be circumvented rather easily. So the solution is a shadow copy of the repo that only gets updated on release and Argo only deploys a specific tag (i.e. release).
We’re not talking about just some enterprise microservice, but stuff in the public administration/government sphere. The tradeoffs are a bit different there.
I didn’t know that GitLab doesn’t allow that! We use BitBucket and there it’s extremely easy to put branch restrictions so that only certain Usergroups are allowed to merge into the release-branches