Slush break requested -- Upgrade gitolite package on pkgs01 (pkgs.fedoraproject.org)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Current situation:

pkgs01 was built partially by puppet and partially by hand.  We never
went through the step of completely rebuilding pkgs01 via puppet.
Recently I (re)discovered that the gitolite package has locally modified
files (4 of them: /usr/bin/gl-auth-command, /usr/bin/gl-compile-conf,
/usr/share/gitolite/hooks/common/update, /usr/share/perl5/gitolite.pm).
 Also most unfortunately it appears I did not keep patch files around,
rather I directly modified files while attempting to make things work.
Shame on me :(

I have spent the last few days working on an updated package for
gitolite for EL6, to go from 1.5.3 to 1.5.7.  Part of this motivation
was to get a new feature for error messages when attempting to clone a
repo that doesn't exist, and the other part is to have proper upstream
support for our setup, eliminating the need to locally modify files.

I have tested the new package on pkgs01.stg.phx2 and adjusted the
gitolite.rc file accordingly (changed in puppet stg branch).  I've
tested that expected access works, and expected denials work as well.
I'm confident that the new package + changes from puppet will work in
production.

I'd like to get pkgs01 production to a state where it can be built
entirely from puppet and function correctly.  There are a couple
different options at this point:

A) Upgrade gitolite package and cherry-pick gitolite.rc changes from stg
in puppet.

B) rebuild existing gitolite package with local modifications done as
patches and make available in the infrastructure repo (and upgrade the
package in production)

C) use puppet hotfix module to stash the modified files so that puppet
puts them in place.

I'm requesting A, and offering to be on-call for this system during the
break, should something go wrong.

More data:

The changes in gitolite between 1.5.3 and 1.5.7 largely don't effect us.
 The biggest change that does is proper upstream support for our setup,
where we don't have gitolite manage ssh files or repo creations.  Our
ACL generation script does not need to change.

Diff of gitolite.rc changes:

diff --git a/modules/gitolite/files/distgit/gitolite.rc
b/modules/gitolite/files
index 4af1be8..03149e3 100644
--- a/modules/gitolite/files/distgit/gitolite.rc
+++ b/modules/gitolite/files/distgit/gitolite.rc
@@ -89,6 +89,9 @@ $GIT_PATH="";

 $GL_BIG_CONFIG = 1;
 $GL_NO_DAEMON_NO_GITWEB = 1;
+$GL_NO_CREATE_REPOS = 1;
+$GL_NO_SETUP_AUTHKEYS = 1;
+

The upstream author of gitolite will be available during the break
should we have any emergency issues.

Summary:

I'm looking for a couple +1s to attempt option A of upgrading gitolite
and merging the gitolite.rc change into production.  I will make backups
of the modified files should we need to roll back the changes.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
_______________________________________________
infrastructure mailing list
infrastructure@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/infrastructure



[Index of Archives]     [Fedora Development]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]

  Powered by Linux