4

簡単なプロジェクトを作成し、マスター ブランチをコミットしてプッシュし、それを保護しました。その後、ユーザーを開発者としてプロジェクトに追加すると、このユーザーはマスターにプッシュできました。
したがって、admin=master、user1=developer です。

変更して user1 としてプッシュすると、マスターにプッシュできました。これを許可しない実稼働インスタンスがあるため、これは奇妙です。

vagrant インストールを使用して、開発環境をセットアップしました。vagrant ssh:
cd /vagrant/gitlabhq && git pull --ff origin master
put me at commit a8b544ed770cf172b09feb6ffee14b1814b66ad4、gitlab-shell
cd /vagrant/gitlabhq && bundle exec foreman start -p 3000
v1.5.0 gitlab が起動して実行されました。

admin@local.host としてログインし
ました 「admin」キーを追加しました シェルで
プロジェクト「master-protected」
を作成し、リポジトリを作成し、ファイルを追加してコミットしてプッシュしました。

「user1」としてキーを追加し、シェルで、user1 が開発者ロールを持つ「マスター保護」を複製しました。

master を変更してプッシュすると、gitlab がプッシュを受け入れ、コミットが gitlab に表示されます。それを否定するべきだった。実際、ブランチ セクションに移動し、マスター ブランチが保護されていることを確認すると、最後のコミットは、開発者権限のみを持っていた "user1" のコミットです。

開発環境でこれが起こっている理由を見つけようとするために、どこをさらに調べることができるかについてのアイデアはありますか? タグ v5.3.0 でも同じで、製品 v5.3.0 では発生しないと確信しています。

面白いことに、マージ リクエストと開発者ロールで保護されていない保護されたブランチで見つけたと思っていた別のバグを再現しようとしていたのですが、これでブロックにぶつかりました。

4

3 に答える 3

2

数か月後にこれをぶつけて申し訳ありませんが、私はこれと同じ問題を抱えており、gitlab-shell 更新フックをチェックすることでこれを解決することができました。

私は Gitlab バージョン 5.1.0-4 を使用しています。私の場合、gitlab-shell/hooks/updateファイルは次のようになります。

#!/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

他の誰かを助けることを願っています。

よろしくお願いします。

ペドロ・フローレス

于 2013-12-02T14:17:49.427 に答える