Deleting repos, post-update, web interface

[Martin Stiborský]

Hello,
first of all, thanks a lot for Gitolite, I really like this project,
happy to work with.

I'm working on git hosting service for projects in the company where
I'm employed (this thing tieto.com/etb). As a part of the solution,
which has gitolite as core thing for user management, we almost
accidentaly end up with development another tool, which is web
interface on top of gitolite-admin repository, it make life easier for
our support team.
What is nice is that this tool will be open-sourced, I don't have
exact date or I can't show the code right now, I can say it's named
WebGitolite, it is written in Python and I'm extremely happy to work
on that. So, I'll push the news here once the code will be out on
GitHub.

By the way, I have few questions :)
Right now, on our git server is installed latest gitolite g2 version.
Sure it will be upgraded soon, I just today tried few things and seems
that it will need little bit more care than I've expected.
For example, directly on git server, in "git" user home, I need there
cloned gitolite-admin repository and this one have to be updated every
time, just after something is pushed to gitolite-admin origin. This
cloned, updated, gitolite-admin is used by GitWeb. Because, we are
using SSO server (Jasig CAS), so I have patched GitWeb, where I can
find out username of logged user and then filter our only those
repositories, which the user can see, and that I can dig out from
latest gitolite-admin repos config files. It works nice :) (btw, this
will be changed, it is my first solution, now I know I can ask
directly gitolite, what permissions an user has…but anyway, I still
need updated gitolite-admin for WebGitolite).
With Gitolite g2 it was easy, just a hook invoked from
gitolite-admin/hooks/post-update, pulling changes in cloned
gitolite-admin.
This I have to change in g3. Right now I'm not 100% sure which way, if
some hook again, or trigger, or some combination with standalone
gitolite command, but anyway it will be more clear solution than now
probably.

Another thing is removing repositories in gitolite g3. We have the
conf file splitted into "one conf per repo" with help of "include" in
gitolite.conf.
Now, when I remove conf file, I got a error "WARNING: split conf not
set, gl-conf present for...", because the actual bare repository still
exists on server, in "repositories/". (Hope I'm not wrong :P). It was
silent in g2…hm, and I've just tried it on my local environment,
because I thought such error somehow broke gitolite until it's fixed
but I was wrong…it works without problem, just the error is in the
output, so, that's ok, nevermind, all of that I can handle in the
WebGitolte. So, take this part just as my note :)

Well, after all it seems that nothing much to ask you in this post :)
Just if you notice something really wrong or in wrong direction,
please let me know, I'm sure you would do so :)

--
S pozdravem / Best regards
Martin Stiborský

Jabber: st...@njs.netlab.cz

[Andreas Stenius]

In g3, you have a ~/.gitolite directory that is your gitolite-admin repo, kept up-to date for you.

That's what gitolite does to work with the admin repo, so you can simply hook into that at no additional cost ;)

(sitaram will correct me if I'm wrong ;)

Cheers,

Andreas

2012/6/18 Martin Stiborský <martin.s...@gmail.com>

[Andreas Stenius]

Oh, and the gl-conf warning. Simply remove the gl-conf file in question (when you are certain that the warning is expected), and the warning will be by gones.

2012/6/19 Andreas Stenius <g...@astekk.se>

[Sitaram Chamarty]

On Tue, Jun 19, 2012 at 1:12 PM, Andreas Stenius <g...@astekk.se> wrote:
> Oh, and the gl-conf warning. Simply remove the gl-conf file in question
> (when you are certain that the warning is expected), and the warning will be
> by gones.

see http://sitaramc.github.com/gitolite/emergencies.html#ue

[Martin Stiborský]

Hello,

thanks for reply, after all, I'm back with additional questions...

~/.gitolite is nice, it helped, at least for GitWEB + CAS integration, I don't have to care about shared gitolite-admin between few linux users (git, webgitolite, apache, each service have own user) anymore.

And my Gitolite UI (WebGitolite) can have now just own clone of gitolite-admin repository to work on top of it...but still, I need the hook, to upgrade that clone... I want to invoke the refresh from gitolite side.

I know VREFs now, it's great, I'm looking for some other usage, because there is for sure something awesome to implement with VREFs.

I have already working, ehm, "proof of concept" of the hook, to invoke refresh of cloned gitolite-admin for WebGitolite, so I guess it may work like that…

Just if you have any more comments, I'd appreciate it.

[Wang Jian]

To make adding/removing repositories easier, you can use wild repo in aggressive
manner: all repos except gitolite-admin.git are wild repos.

Then you can give some special accounts RW+D permissions, like this

@superadmin = you

repo p/..*
    C = @superadmin
    RW+D = @superadmin
    RW+D = MANAGERS
    RW = WRITERS
    R = READERS gitweb daemon

Then you can hook your removing repository code on 'D' command.

You only need to manipulate user groups in gitolite.conf and
repos.git/gl-perms. You can hook to 'perms' command for latter.


在 2012年6月19日星期二UTC+8上午4时21分57秒，Martin Stiborský写道：

[Martin Stiborský]

Hi all, I'll try to explain my situation and intention, hope you understand despite of my bad english...

As I said earlier in this thread, I'm working on webinterface for Gitolite.

Basically, it operates on top of gitolite-admin repository, when you do some change in for example repository config file via that webinterface, in background are called git commands, it stage the change, commit and push…it emulates command line work.

So, it needs clone of gitolite-admin repo and it have to be up to date - for example, I can push some change to gitolite-admin via command line and that cloned gitolite-admin for webinterace will be outdated. 

With gitolite g2 I have had solved this with small modification in post-update hook in origin gitolite-admin. There was just a call to pull changes in the cloned gitolite-admin and this way it was kept up to date all the time.

Sure, I can try to pull changes directly in the webinterface application, before any action, but this means some troubles and for me sounds better invoking the refresh of the gitolite-admin repo from gitolite side.

Unfortunately, VREF is not solution for this probably, because it's processed before the push is actually passed to repository. I tried that, because of not understanding all the thing completely. 

I haven't checked gitolite triggers yet, so I'm not sure if there is a chance, but the best place for this is the post-update hook I guess.

It would be nice to have there some space for my intention :)

I hope it's little bit more clear... I'm thinking if I'm not completely wrong with the solution...hope not. 

[Sitaram Chamarty]

On Thu, Jul 26, 2012 at 9:29 PM, Martin Stiborský
<martin.s...@gmail.com> wrote:

> So, it needs clone of gitolite-admin repo and it have to be up to date - for
> example, I can push some change to gitolite-admin via command line and that
> cloned gitolite-admin for webinterace will be outdated.
> With gitolite g2 I have had solved this with small modification in
> post-update hook in origin gitolite-admin. There was just a call to pull
> changes in the cloned gitolite-admin and this way it was kept up to date all
> the time.

you were pulling changes in a script? That's never a good idea -- how
would you handle conflicts?

[milk]

On Thu, Jul 26, 2012 at 8:59 AM, Martin Stiborský
<martin.s...@gmail.com> wrote:
> So, it needs clone of gitolite-admin repo and it have to be up to date - for
> example, I can push some change to gitolite-admin via command line and that
> cloned gitolite-admin for webinterace will be outdated.

Sounds like a push to the cloned gitolite-admin in post-update would fix this.

-milki