Docker-gitlab: All master branches are protected with upgrade to 8.14.1

Created on 2 Dec 2016 · 30Comments · Source: sameersbn/docker-gitlab

Not sure what's happened but after upgrading from 8.14.0 to 8.14.1 all the master branches in all repos have had their status changed to protected, maybe more bad migration or something? Anyone else had this issue? All other branches seem to be OK.

I know its not the end of the world because changing back to unprotected works fine, but thought I'd mention it 👍

Source

adamlc

👍14

Most helpful comment

FYI, you can release a quick patch by installing an older version of git still available on the Ubuntu servers:

apt get install -y git=1:1.9.1-1ubuntu0.3 git-man=1:1.9.1-1ubuntu0.3

jasl8r on 7 Dec 2016

👍6

All 30 comments

That is the default behavior for GitLab (src: protected_branches.html). I don't know when it became default, since a commit on July 22 implies the verbiage (on line 13 of the old version) was already there at that time.

I'm still on sameersbn/gitlab:8.14.0 and my master branches are all protected (and I've done nothing to set or change them).

I'm not saying this is not an issue. If you had previously unprotected all of your master branches, or the branches were created before this became the default mode in GitLab, then who knows.

If that's the case, then it's likely something for GitLab issues, not here, since I believe this docker image is not doing anything that specific to repos.

r2evans on 2 Dec 2016

I upgraded as well from 8.14.0 to 8.14.1, and now I can't push to my protected branches that I could push to before. Getting error saying "remote: GitLab: You are not allowed to force push code to a protected branch on this project" even though I am not force pushing. But yeah, most likely this is an issue for GitLab.

gilyes on 3 Dec 2016

👍5

Users belonging to the "Masters" list can push to the master branch. I think only the repo owner (since it is a per-repo setting) can change this, but perhaps other "Masters" can do it as well.

To find the list, within the repo pull down the "repo gear" (top-right corner, typically under the user avatar) and select "Members". Each member that has been granted access will be specifically listed as a "Master" (among "Guest", "Reporter", "Developer", and "Master"). If instead of "Members" you go to "Protected Branches", the level required to push can be set. "Merge" ops can be "Masters" or "Masters+Developers", while "Push" ops can be restricted to "Masters", "Master+Developers", or "No one".

Odd that the behavior appears to be have modified from what was there before. Are you certain it changed at exactly the transition from 8.14.0 to 8.14.1? (Not that your answer here will affect my ability to help, but it might be useful if/when you take it to GitLab Issues.)

r2evans on 3 Dec 2016

Yes, the issue started immediately after upgrading to 8.14.1. I am the Owner on those repos and tried all combinations with no success. If I take off branch protection all is good. Given the actual error message (talking about force push) if GitLab somehow thinks I am force pushing then it is expected to reject it. But I am not force pushing, Tried it from different machines, different repos, same result.

gilyes on 3 Dec 2016

👍2

I'm stumped, sorry. (And GitLab is a bit swamped, you may not get much from them.) I suggest going to GitLab Issues as well as posting to ServerFault and/or StackOverflow (for community response).

r2evans on 3 Dec 2016

Yeah, I might do that thanks.

gilyes on 3 Dec 2016

According to this comment the issue preventing regular push to protected branches may be caused by a change in behavior between Git versions.

Essentially, the output of a git command in a specific scenario apparently changed from empty to a non-empty string, causing GitLab to erroneously think that a regular push is forced push.

The commenter reverted the GitLab container's Git version from 2.11 to 1.9.1 and the issue disappeared.

gilyes on 4 Dec 2016

I'm seeing this issue as well (rejected force push when performing a regular push). Let's hope it is resolved quickly upstream.

evenh on 5 Dec 2016

👍1

The defaults for protection has been like that for a long time, the problem we see is that we can't push to a branch which has protection even if it isn't a force-push.

I now see these errors after upgrading to 8.14:

https://gitlab.com/gitlab-org/gitlab-ce/issues/25301#note_19420235

thomasf on 5 Dec 2016

Ahh didn't realise that was the default behaviour, but I guess this bug in git bought it to my attention. I'm not sure what implications downgrading git would have in the container. Its probably worth waiting for an upstream fix I'd say.

adamlc on 5 Dec 2016

FYI, you can release a quick patch by installing an older version of git still available on the Ubuntu servers:

apt get install -y git=1:1.9.1-1ubuntu0.3 git-man=1:1.9.1-1ubuntu0.3

jasl8r on 7 Dec 2016

👍6

Seeing the same issue on the published 8.14.4 image still. Can't push to master even though it's a regular push (non-forced) and I'm a project "Master".

Klowner on 12 Dec 2016

@jasl8r, is downgrading to 1.9.1 a safe workaround? GitLab says the minimal compatible Git version is 2.8.

galet on 12 Dec 2016

I would recommend to downgrade to a version like 2.10.2 Currently I don't know where you can get from the ubuntu space. I look into it in the evening.

solidnerd on 12 Dec 2016

👍2

I believe 1.9.1 is fine for now. According to this discussion the main reason for the requirement is due to security issues that have been backported in the Ubuntu release. It looks like 2.7+ is required to render the 'deployed at' text, but it appears that just falls back to a basic 'deployed to environment' link instead.

Alternatively you can just compile git from source...

jasl8r on 12 Dec 2016

Sorry @solidnerd, I looked but didn't see this.

I'm trying to make a fix. The other version in Ubuntu 14.04 is 1.9.1 which is too old. Gitlab wants git version 2.8.4.

The git maintainers ppa won't work as it only has 2.11.0, 2.4.6 and 2.3.7.

lyda on 12 Dec 2016

Testing a fix now. Pull request soon.

lyda on 12 Dec 2016

Note that I've gotten this to build, but have not yet deployed to see if it fixes the issue. For dumb reasons this will require me to build it a second time and the deploy it. Which will take a while. However I think it should address the issue.

lyda on 12 Dec 2016

@lyda, nice, thanks for going that route. Do you know if the client version of git (not within the GitLab environment) impacts the issue, or is it just the git that GitLab uses internally?

r2evans on 12 Dec 2016

The version git uses internally causes the issue. I was seeing the issue
with git 2.9.3 on my laptop, but just from reading the bug it's clear that
it's being caused on the server (gitlab) side. I'll try and fix it on the
gitlab side tomorrow.

lyda on 12 Dec 2016

👍2

@lyda, looks like your temporary patch will be much needed, as the upstream fix may be taking a bit more work to accept. (But they do "confirm" the problem is the internal git-2.11, and downgrading to git-2.10.2 appears to temporarily fix the symptom.)

r2evans on 13 Dec 2016

The upstream has fixed the issue on Gitlab 8.15. https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

I think we could follow the upstream version to deal with this problem.