La branche protégée de Gitlab ne protège pas la branche sur ssh push

Question

J'ai créé un projet simple, commis et poussé la branche master, puis je l'ai protégé. Après cela, j'ai ajouté un utilisateur au projet en tant que développeur et cet utilisateur a été autorisé à pousser vers master.
Donc admin=maître, user1=développeur.

Lorsque j'ai modifié et poussé en tant que user1, j'ai été autorisé à pousser vers master. C'est étrange car j'ai une instance de production qui ne le permet pas.

J'ai utilisé l'installation vagrant pour mettre en place un environnement de développement. Après le ssh de vagrant :
cd /vagrant/gitlabhq && git pull --ff origin master
me mettre au commit a8b544ed770cf172b09feb6ffee14b1814b66ad4, gitlab-shell v1.5.0
cd /vagrant/gitlabhq && bundle exec foreman start -p 3000
gitlab était maintenant opérationnel.

Je me suis connecté en tant que admin@local.host
J'ai ajouté ma clé "admin".
Création du projet "master-protégé".
dans un shell, j'ai créé le repo, ajouté un fichier, commis et poussé.

En tant que "user1", j'ai ajouté ma clé, et dans un shell, j'ai cloné "master-protected" pour lequel user1 a un rôle de développeur.

Quand j'ai modifié et poussé master, gitlab a accepté le push, et le commit apparaît directement dans gitlab. Il aurait dû le refuser. En fait, lorsque vous allez dans la section branches, et que vous voyez la branche master comme étant protégée, son dernier commit est celui de "user1" qui n'avait que des permissions de développeur.

Avez-vous une idée de l'endroit où je peux chercher pour essayer de trouver pourquoi cela se produit dans l'environnement de développement ? C'est la même chose pour le tag v5.3.0 également, et je suis certain que cela ne se produit pas dans la production v5.3.0.

C'est drôle parce que j'essayais de reproduire un autre bogue que je pensais avoir trouvé avec les branches protégées qui n'étaient pas protégées par les demandes de fusion et les rôles de développeur, mais je me suis heurté à un blocage avec celui-ci.

Answer 1

Désolé de revenir sur ce sujet plusieurs mois plus tard, mais j'ai le même problème et j'ai réussi à le résoudre en vérifiant le hook de mise à jour de gitlab-shell.

J'ai la version 5.1.0-4 de Gitlab et dans mon cas, la gitlab-shell/hooks/update devrait ressembler à ceci :

#!/usr/bin/env /opt/gitlab-5.1.0-4/ruby/bin/ruby

# This file was placed here by GitLab. It makes sure that your pushed commits
# will be processed properly.

refname = ARGV[0]
key_id  = ENV['GL_ID']
repo_path = `pwd`

require_relative '../lib/gitlab_update'

GitlabUpdate.new(repo_path, key_id, refname).exec

J'espère que cela aidera quelqu'un d'autre.

Meilleures salutations.

Pedro Flores

Answer 2

Cela peut être dû au fait que l'utilisateur est un administrateur, (Un utilisateur peut être admin y developer ) :

Voir : https://github.com/gitlabhq/gitlabhq/issues/7723#issuecomment-63287902

Suppression de admin privilèges de l'utilisateur a résolu le problème pour moi.

Answer 3

J'ai eu le même problème, dans mon cas le problème était un lien symbolique 'hooks' cassé dans le dossier du projet.

lrwxrwxrwx   1 git git    28 Sep 29  2015 hooks -> /home/git/gitlab-shell/hooks

En corrigeant le lien comme ci-dessus, le problème est résolu