Per repo hook management

Issue #813 resolved
David Vega created an issue

It would be very useful to have this. Example use case:

Some of the repos I work on are integrated to Perforce through the perfarce extension, so hooks need to be added to these repos so that they can sync to Perforce before accepting a push or serving a pull, however this does not apply to all repos and would actually break those not using the perfarce extension.

This feature should also support hooks for git under the same UI.

Comments (10)

  1. Andrew Kesterson

    Marcin - This was actually going to be my next patch, I didn't know there was already an issue for it.

    The issue with allowing per-repo hook management is that it puts all the burden on the site maintainer to verify the sanity of, and assign out, all the hooks on the repos. Otherwise, if we let the repo owners build their own hooks, we have to make sure we're not introducing madness into the system and allowing execution of arbitrary privileged code.

    Thoughts?

  2. Marcin Kuzminski repo owner

    I always recommended people to use rcextensions for that, and put there the logic what should be executed on which repo. Also the custom stuff in rcext is post-push, and wouldn't break push transaction.

    advantages:

    • it gives you just one entry point of custom code executed.

    disadvantages:

    • unable to verify push (because of post-push)
    • you have to edit code on server to make changes.

    custom hooks are cool feature, but i see some issues.

    • security as you pointed in "we have to make sure we're not introducing madness into the system and allowing execution of arbitrary privileged code."

    • the hell of making it work for git due to how hooks are handled there (pre-receive/post-receive files and custom code in there)

    • Should we only allow this for owner, when there could be multiple admins on a repo.

    regarding security i feel it's really serious lost password for one user could compromise whole server. I don't have a sane solution to this now.

  3. David Vega reporter

    How about if this is just limited to the global admins?, since it is already allowed globally for all repos this is just a step in granularity, not in actual permissions

  4. Marcin Kuzminski repo owner

    since 1.6 we just killed duality of setting page for global admins vs repo admins, since it was confusing, and no one liked it. If we say just global admins, why not get back to rcext ?

    i guess if you write custom hooks it would be callable, than anyway you would need to upload to server, in the ends nearly as much work as writing stuff int rcext module ?

  5. Andrew Kesterson

    Let's assume that anyone who wants to write custom hooks is willing to go through the trouble of uploading them to the server, and implementing whatever sanity checking/quality assurance process their site admin is comfortable with. So whether that's rcext, or whatever, let's assume they're comfortable with it.

    In the Admin settings, we could make a new page, call it "hooks" or "rcext config" or something. There, the site maintainer could setup the list of available hooks; they could select a number of scripts/modules to make available to repo owners as hooks, even going so far as to say "mercurial repos can use these, git repos can use these, and all repo types can use these". Then the repo owners, on the repo settings page, could assign the hooks to their repo from a dropdown menu, from the list of available ones supplied by the site admin. And if someone wants to add a new completely custom hook, they have to submit it to the site maintainer for inclusion (which is the way that both BitBucket and GitHub do it).

    Sounds like a decent compromise to me?

  6. Alexey Larikov

    One more disadvantage of rcextension is that implementing per-repo behavior requires code hacking for every new or deleted repository.

  7. Marcin Kuzminski repo owner

    @akesterson yeah that would make sense, i wanted to create webhooks for rhodecode for long time, and that would be perfect use case for it.

  8. Andrew Kesterson

    Given that you can technically already do this with rcext, I recommend downgrading this from Critical to something less severe. The community will survive until someone gets to it, I think.

  9. Marcin Kuzminski repo owner

    I agree.

    What i also forgot to mention that for Mercurial, there's another entry point for global hook, and that is an advanced section in the hooks config in admin settings. It enables you to enter a callable mercurial style hook that will be called for EACH repository. Only thing i don't like about that it's Mercurial specific.

  10. Marcin Kuzminski repo owner

    Per-repo settings is now implemented and will be a part of 3.7.X releases of RhodeCode. It will allow to change mercurial/gt hook/issue tracker settings globally and on each repository.

  11. Log in to comment