this post was submitted on 21 Jul 2023
170 points (94.3% liked)

Programmer Humor

32453 readers
601 users here now

Post funny things about programming here! (Or just rant about your favourite programming language.)

Rules:

founded 5 years ago
MODERATORS
 
top 12 comments
sorted by: hot top controversial new old
[–] [email protected] 17 points 1 year ago (1 children)

Assuming we are taling about git. How can you merge to the wrong repo? You mean the wrong remote repo?

[–] [email protected] 13 points 1 year ago (2 children)

Yes, we have 5 times the same repo, because of security or something. You are supposed to merge from 0 to 4. If you merge 2 commits into 3 and another one into 4, we are going to have a little problem.

[–] [email protected] 33 points 1 year ago

That's the dumbest solution ever.

[–] [email protected] 18 points 1 year ago* (last edited 1 year ago) (1 children)

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?

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 4 points 1 year ago (1 children)

But.. also in ArgoCD you just set up which branch you want to look at

[–] [email protected] 4 points 1 year ago (1 children)

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.

[–] [email protected] 5 points 1 year ago (1 children)

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

[–] [email protected] 4 points 1 year ago (1 children)

Bitbucket also doesn't enforce these rules properly. You can simply change the rules, merge, then change back.

The only way around that is to restrict every developer account into oblivion and only have an ops guy as repo admin, but I think most ops teams have better things to do.

[–] [email protected] 4 points 1 year ago (2 children)

Why should a developer be a Repo admin? Thats DevOps territory

[–] [email protected] 4 points 1 year ago

That very much depends on your workflow and team setup. Repo admin for me means "can alter who and how branches can be merged". That's usually a job for lead devs.

[–] [email protected] 1 points 1 year ago

Aah, DevOps as a separate role... Now that's a dream I can get behind...

load more comments
view more: next ›