Ответ 1
У меня была эта проблема, потому что у меня была master
как защищенная ветвь
Как только я не защитил ветвь, я смог нажать тонкой
Я установил свой собственный сервер (дома), и я добираюсь до него с помощью шпатлевки на моем основном ПК.
Gitlab установлен и настроен, я могу достичь gitlab и войти в систему. Но когда я пытаюсь передать файлы (через HTTP) в свой собственный проект, я получаю это сообщение:
POST git-receive-pack (381 bytes)
remote: GitLab: You are not allowed to access master![K
remote: error: hook declined to update refs/heads/master[K
To http://myserver.com/root/push2jump.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'http://myserver.com/root/push2jump.git'
Я использую HTTP вместо SSH, потому что там я получаю "Access denied", поэтому в принципе и не работает.
Когда я запускаю
sudo bundle exec rake gitlab:check RAILS_ENV=production
Он говорит мне, что Sidekiq script не работает (что я не могу исправить, не уверен, связано ли это с этой проблемой) Конечно, он говорит мне, что репозиторий пуст. Остальное кажется прекрасным.
Я проверил
.ssh/authorized_keys
Что тоже кажется правильным, ключ такой же, как и мой сохраненный ключ.
И мой repos_path в gitlab-shell/config.yml выглядит хорошо, не используя symlink:
repos_path: /home/git/repositories/
Я запустил руководство по установке gitlab.
Может ли кто-нибудь помочь мне с этой проблемой? Спасибо заранее
ОБНОВЛЕНИЕ
System information
System: Ubuntu 12.04
Current User: git
Using RVM: no
Ruby Version: 2.0.0p481
Gem Version: 2.0.14
Bundler Version:1.6.2
Rake Version: 10.3.1
Sidekiq Version:2.17.0
GitLab information
Version: 6.9.2
Revision: e46b644
Directory: /home/git/gitlab
DB Adapter: mysql2
URL: ***
HTTP Clone URL: ***/some-project.git
SSH Clone URL: ***:some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 1.9.4
Repositories: /home/git/repositories/
Hooks: /home/git/gitlab-shell/hooks/
Git: /usr/local/bin/git
У меня была эта проблема, потому что у меня была master
как защищенная ветвь
Как только я не защитил ветвь, я смог нажать тонкой
Убейте его и начните снова с издания Omnibus Gitlab.
Единственное, что вам нужно, чтобы запустить его на 64-разрядном Ubuntu - не знаете, почему у них нет 32-битного, но там вы.
Я спустился по инсталляционной переустановке-try-again, пока я просто не пошел с изданием Omnibus.
Два "раздражающих" вещей: установка Omnibus Gitlab использует веб-сервер Nginx, а не Apache (но для этого есть веская причина, учитывая, что Nginx не открывает новый процесс для каждого соединение)... и вместо нее используется PostgreSQL, а не MySQL для своей базы данных. Для использования домашнего/домашнего офиса, конечно, вы можете установить PostgreSQL и MySQL на одном компьютере. Менее очевидно, как запустить Apache и Nginx, или действительно, как заставить Nginx запускать несколько виртуальных серверов при сохранении Gitlab.
У меня были очень похожие симптомы, и я решил проблему через изменение членства в проекте. Сообщение об ошибке, которое я получил от TurtoiseGit после попытки нажатия:
git.exe push -progress "origin" master: master
Подсчет объектов: 14, сделано. Дельта-сжатие с использованием до 4 потоков. Сжатие объектов: 100% (7/7), сделано. Написание объектов: 100% (8/8), 857 байт | 0 байт/с, сделано. Всего 8 (дельта 3), повторно используется 0 (дельта 0)
remote: GitLab: вам не разрешен доступ к мастеру! удаленный: ошибка: hook отказался обновить refs/heads/master
В git @gitlab.int.mycompany.com: datascience/compliance.git! [дистанционный пульт reject] master → master (отклонение крюка) ошибка: не удалось нажать некоторые refs to git @gitlab.int.mycompany.com: datascience/compliance.git '
git не вышел чисто (код выхода 1) (33181 мс @6/27/2014 9:50:32 AM)
В страницах admin gitlab я обнаружил, что я не был участником проекта, к которому я пытался нажать. Я был членом проектной группы, но не был проектом.
После того, как я добавил себя в качестве члена проекта, мой push удался без ошибок.
Просто у меня была ошибка You are not allowed to access master!
в хранилище, в котором я находился. Ни один из параметров защищенной ветки не изменился. Проблема возникла сразу после выполнения резервного копирования сервера GitLab; возможно, сервер находился в плохом состоянии. После выполнения моей настройки GitLab мне удалось снова нажать:
gitlab-rake gitlab:check
Руководство по устранению неполадок GitLab. Соблюдайте эту проблему в GitLab 7.4.3.
Первоначально я думал, что это проблема защищенного ветки. Мне показалось странным, что я потерял доступ к филиалу репозитория, которым я был владельцем. После отключения защиты в филиале нажатие все же привело к той же проблеме доступа. Восстановление защищенной ветки оставило меня в том же состоянии. Я выполнил проверку GitLab (упомянутый выше), которая, как представляется, решила проблему.
в моем случае это потому, что unicorn-порт был занят другим Java-процессом, добавьте эту строку unicorn ['port'] = 8090 на /etc/gitlab/gitlab.rb и запустите: sudo gitlab-ctl reconfigure