Protected Branches are problematic for mirroring

Matthew Finkel:

Matthew Finkel created an issue: #38 (closed)

CC: @ahf @gk

With #9 (closed) we got cloning/mirroring between gitolite and gitlab. Ignoring #36 (moved) for now, it seems we have a problem with using protected branches. Specifically, we configured protected branches for '*' and disable merging via the web interface, and 'Maintainers' are allowed push access. This seemed like it was close enough to what we wanted, however we now have another problem.

` remote: remote: GitLab: You can only delete protected branches using the web interface.

I wonder what was supposed to get deleted here. Given that the only thing that was about to happen was the creation of maint-9.5 on Gitlab. Hrm. How did you push to git.tpo?

remote: To dip.torproject.org:tpo/applications/tor-browser-build remote: ! [remote rejected] 20254-update-marsigning-check-sh-to-cope-with-signed-os-x-mar-files (pre-receive hook declined)

Where is that one coming from? As far as I can see there is no such branch on Gitlab nor on git.tpo:

https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/branches/all

remote: ! [remote rejected] maint-9.5 -> maint-9.5 (pre-receive hook declined) remote: ! [remote rejected] refs/merge-requests/2/head (pre-receive hook declined) remote: ! [remote rejected] refs/merge-requests/3/head (pre-receive hook declined) remote: ! [remote rejected] refs/merge-requests/3/merge (pre-receive hook declined)

Hrm. Weird. How did you actually solve the issue given that there is no a maint-9.5 branch on Gitlab which is up-to-date.? `

Specifically, the description of Protected Branches includes:

prevent anyone from deleting the branch

prevent anyone from force pushing to the branch

I guess we need a different approach.

Not sure yet because I think we actually want to have those properties :). I guess you hit

"When a protected branch or wildcard protected branches are set to No one is Allowed to push, Developers (and users with higher permission levels) are allowed to create a new protected branch as long as they are Allowed to merge." (see:https://gitlab.torproject.org/help/user/project/protected_branches)

? Which does not explain the "you can only delete protected branches part" but would make sense for issues with creating maint-9.5. I'd find it not too much hassle to flip the switch for "Allowed to merge" in case we need to create a new branch and set it back afterwards.

Hm. Interesting.

I think maybe I need some help here from @hiro where we look at how the Git to Gitlab sync hooks works on Gitolite.

I think the sync scripts does something that ensures that anything in the destination is cleaned up, so maybe it does something that is considered a deletion.

assigned to @ahf

added Next label

mentioned in issue #36 (moved)

Georg Koppen:

Georg Koppen commented:

Matthew Finkel:

Matthew Finkel created an issue: #38 (closed)

CC: @ahf @gk

With #9 (closed) we got cloning/mirroring between gitolite and gitlab. Ignoring #36 (moved) for now, it seems we have a problem with using protected branches. Specifically, we configured protected branches for '*' and disable merging via the web interface, and 'Maintainers' are allowed push access. This seemed like it was close enough to what we wanted, however we now have another problem.

` remote: remote: GitLab: You can only delete protected branches using the web interface.

I wonder what was supposed to get deleted here. Given that the only thing that was about to happen was the creation of maint-9.5 on Gitlab. Hrm. How did you push to git.tpo?

Still not knowing what exactly happened I guess the "Deletes source branch" option was selected and that's not allowed due to protected branches. Thus, the error showed up. I guess we could easily work around that issue by not ticking that option.

mentioned in merge request tpo/applications/tor-browser-spec!2 (closed)

Georg Koppen:

Georg Koppen commented:

Georg Koppen:

Georg Koppen commented:

Matthew Finkel:

Matthew Finkel created an issue: #38 (closed)

CC: @ahf @gk

With #9 (closed) we got cloning/mirroring between gitolite and gitlab. Ignoring #36 (moved) for now, it seems we have a problem with using protected branches. Specifically, we configured protected branches for '*' and disable merging via the web interface, and 'Maintainers' are allowed push access. This seemed like it was close enough to what we wanted, however we now have another problem.

` remote: remote: GitLab: You can only delete protected branches using the web interface.

I wonder what was supposed to get deleted here. Given that the only thing that was about to happen was the creation of maint-9.5 on Gitlab. Hrm. How did you push to git.tpo?

Still not knowing what exactly happened I guess the "Deletes source branch" option was selected and that's not allowed due to protected branches. Thus, the error showed up. I guess we could easily work around that issue by not ticking that option.

After thinking a bit more: it should not be an issue with protected branches as the source branches are in the user repository. And I assume the policy regarding those branches is not as restrictive as it is in our non-user repositories. So, a new theory would be that maybe the torproject-pusher is just not allowed to mess with user repositories?

added Doing label and removed Next label

I've tried to do the following now:

Everybody in the tpo/applications group have been "downgraded" to "Reporter" level.
@gk and @sysrqb have two new users (@gk-owner and @sysrqb-owner) that has "Owner" level permissions.
@torproject-pusher have maintainer access on tpo/applications/tor-browser and should thus be able to push from Gitolite to Gitlab.
The protected branches have been removed.

This should mean that nobody have the green merge button during the daily work AND the bot should be able to do "clean" syncs.

Does this sound right or am I missing something here?

mentioned in issue #15 (closed)

Looks like this upstream issue is affecting this plan badly: https://gitlab.com/gitlab-org/gitlab/-/issues/15638

Reporter level users cannot modify labels on merge requests.

I just tried pushing to tpo/applications/tor-browser-build and I received:

remote: == gitlab-push == 
remote: remote: GitLab: You are not allowed to push code to protected branches on this project.        
remote: To dip.torproject.org:tpo/applications/tor-browser-build
remote:  ! [remote rejected] master -> master (pre-receive hook declined)
remote: error: failed to push some refs to 'dip.torproject.org:tpo/applications/tor-browser-build'
remote: == irc-message ==

Also, I don't know how to login using @sysrqb-owner and look at the settings

If you forgot your password you can reset it.

If you forgot your password you can reset it.

Thanks! (I didn't forget it, but using the "Forgot Password" flow allowed me to set it)

I logged in and I found that all tor-browser-build branches were protected, so I modified it.

removed Doing label

Is this issue resolved?

added Next label

changed the description

marked #67 (closed) as a duplicate of this issue

marked this issue as related to #67 (closed)

mentioned in issue #67 (closed)

Hey sorry to be annoying, but is there a way to reset our mirror of https://gitlab.torproject.org/cohosh/snowflake-webext/ to temporarily resolve the issue in #67 (closed) if this will take a while to solve more generally? It is becomming difficult for reviewers to tell which commits belong to the merge request and which are because the mirror is outdated.

Hi Cecylia, Can you unprotect the branch or if the branch is not in a Fast Forward state maybe you could force push?

Oh, thanks! I unprotected the branch and was able to force push an update to it to match gitweb.

added Backlog label and removed Next label

added Icebox label and removed Backlog label

removed Icebox label

added Backlog Icebox labels

removed Icebox label

so the latest 13.5 gitlab release (which we are now running) should fix this issue: there is now an option to allow deploy keys to push to protected branches. the deploy keys must have access to the protected branch, just as a regular user, however, see the documentation for details.

so i'm not sure how the deploy keys were setup here, but presumably this already work?

can someone try protecting a branch and pushing to it again?

thanks!

so the latest 13.5 gitlab release (which we are now running) should fix this issue: there is now an option to allow deploy keys to push to protected branches. the deploy keys must have access to the protected branch, just as a regular user, however, see the documentation for details.

so i'm not sure how the deploy keys were setup here, but presumably this already work?

We don't have any deploy keys set up but we could try playing with it. I wonder, though, how this is supposed to solve this problem...

i'm a bit confused, because the latest 13.9 release announced again that deploy keys could push to protected branches:

https://docs.gitlab.com/ee/user/project/protected_branches.html#allow-deploy-keys-to-push-to-a-protected-branch

but it seems like this issue should now be fixed. it's just a matter of someone testing it, at this point.

could we just assume this is fixed now and move on?

i'll just close this ticket, do reopen if you can't figure it out.

closed

mentioned in issue team#40472 (closed)

marked this issue as related to #15 (closed)

Protected Branches are problematic for mirroring

Child items ...

Activity