Learn more about these different git repos.
Other Git URLs
Due to the way gitolite checks the update hook when a repo is accessed [1], creating the update hook by BaseHook (this is called by set_up_project_hooks when repoSpanner is not used) makes it impossible to do anything with a repo when using gitolite. E.g. pulling/pushing/checking out would return similar error:
update
BaseHook
set_up_project_hooks
FATAL: R any rpms/pagure-e2e-tests bkabrda DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
I think the proper course of action would be to not create the update hook when gitolite is used, but I'm not 100 % sure about that.
[1] https://github.com/sitaramc/gitolite/blob/master/src/lib/Gitolite/Common.pm#L255
Hm pagure.io and src.fp.o are both running gitolite w/o repoSpanner and do not seem to have this issue
@pingou do these two deployments have gitolite version that contains the update_hook_present function that contains the referenced line return 1 if $x and $x eq "$ENV{GL_ADMIN_BASE}/hooks/common/update";? If so, I don't understand why they work :)
update_hook_present
return 1 if $x and $x eq "$ENV{GL_ADMIN_BASE}/hooks/common/update";
@bkabrda do you know the exact file to check?
It's running gitolite3-3.6.7-5.el7.noarch
gitolite3-3.6.7-5.el7.noarch
@pingou it's in Gitolite/Common.pm: https://github.com/sitaramc/gitolite/blob/66a6bec4c62a203a9a54b32d2449bfae8030dfae/src/lib/Gitolite/Common.pm#L249 so likely /usr/share/gitolite3/lib/Gitolite/Common.pm. I have gitolite3-3.6.10-1.el7.noarch - I'll try to see if the different versions could have caused this.
Gitolite/Common.pm
/usr/share/gitolite3/lib/Gitolite/Common.pm
gitolite3-3.6.10-1.el7.noarch
Yup, this is functionality added in gitolite 3.6.10: https://github.com/sitaramc/gitolite/commit/30f49dc5550f9b551eee374f547997c73af0c99b
That also explains why I only started seeing this recently, as I rebuilt my sshd image, it got the newer version of gitolite3 from EPEL and I started seeing the bug.
This is going to be a problem on Mageia and openSUSE, as both ship that version of Gitolite v3.
I had the exact same issue with the last pagure version from EPEL. I have downgraded to gitolite3-3.6.7-7.el7.noarch and then clone via ssh started to work.
I also had the exact same issue and dug a bit deeper. The weird thing was that I was able to create repositories through the gitolite-admin repository itself and then clone them.
So I created one repository with the gitolite-admin and one with pagure and checked the hooks. What I saw was that gitolite added an extra '/' in the symbolic link to the update script. I deleted the symbolic link from the repository created by pagure and created a new symbolic link with the extra '/' in it. And it just works!
For example, Pagure creates in /srv/git/repositories/testing.git/hooks/:
/srv/git/repositories/testing.git/hooks/
update -> /srv/git/.gitolite/hooks/common/update
Gitolite create:
update -> /srv/git//.gitolite/hooks/common/update (mind the extra '/' after /srv/git/)
I'm on CentOS 7 with gitolite3-3.6.11-1.el7.noarch installed
gitolite3-3.6.11-1.el7.noarch
Just a heads-ups that this bug also affects Debian testing/sid, with gitolite3-3.6.11-2.
gitolite3-3.6.11-2
Metadata Update from @ngompa: - Issue set to the milestone: 6.0
We're planning to drop Gitolite support entirely with Pagure 6.0.
cc: @wombelix
Metadata Update from @ngompa: - Issue priority set to: High - Issue tagged with: bug, debt
I've dropped repoSpanner support from the codebase, so next on the chopping block is Gitolite support.
Metadata Update from @wombelix: - Issue assigned to wombelix
I will give it a try to remove Gitolite.
Login to comment on this ticket.