* Eric Schrock <eric.schrock at sun.com> [2008-07-16 22:46]: > On Wed, Jul 16, 2008 at 03:38:39PM -0700, Bill Sommerfeld wrote: > > > > > In the meantime, without this setting, *none of the hooks run*. That's > > > your gate check hooks, your generate a webrev hooks, etc. > > > > > > We had way too many accidentally-hidden putbacks happen due to this > > > setting not being there. > > > > if you need to force hooks to run, you need to set up a captive shell > > environment on the system hosting the gate and funnel all pushes through > > that captive environment. > > It would seem like solving this problem is a requirement for ON > migrating from teamware. It was my understanding that executing the > hooks is a requirement, as it replaces (and improves upon) the ex > post-facto gatekeeper scripts run via teamware's notifications. > > If the default disposition of a mercurial gate is to ignore such hooks > and allow you to putback anyway, regardless of any implementation > details, something seems very wrong. > > Or is it the case that we don't care about people running the hooks? As > it stands today, users have to opt-in to such treatment, and even then > it requires disabling security checks across all hg invocations, not > just operations on onnv.
I believe we're in a better understood situation than these paragraphs suggest. For SSH, you can either use a captive shell environment, as Bill writes and is already implemented for hosting on opensolaris.org, or you can use a shared account, by populating it with the keys of your approved committers. (NFS commits are already not permitted in the current TeamWare configuration.) Which we choose for the temporary period where the ON gate is still on SWAN is the decision. - Stephen -- sch at sun.com http://blogs.sun.com/sch/
