[vtk-developers] Auto install git hooks

[Marcus D. Hanwell]

So, I was thinking about this over the weekend, and talked to Brad King.
There is an environment variable that is set by CTest when it drives the
build. I can check if that variable is defined, and know that CTest is
driving the build.

If I did that then when a user first configures VTK CMake will print an
error with copy/paste instructions to check out the local hooks (along with
a link to the wiki). They can set a CMake cache variable to ignore the hooks
to get past it if they wish. If you are not in a git checkout the whole
process is skipped.

If CTest invoked the configure then the environment variable is set, and so
the error is not raised - negating the need to set a cache variable on all
of the dashboard machines. The only assumption is that CTest is driving the
build, which I think is reasonable. I tested the logic out in Titan and it
looks good.

Does this cover all of your requirements reasonably? I will be checking this
code into Titan as I think it is an improvement on what we had there too. I
would be happy to check the relevant portion into VTK.

Marcus

On Thu, Jun 17, 2010 at 6:33 PM, Moreland, Kenneth <kmorel at sandia.gov>wrote:
>
>
> In short, a pushurl is not a good indication of whether commits will be
> made or whether those commits will eventually be pushed to the main
> repository.
>
> -Ken
>
>
>
> On 6/17/10 2:46 PM, "Marcus D. Hanwell" <marcus.hanwell at kitware.com>
> wrote:
>
> On Thu, Jun 17, 2010 at 4:40 PM, Clinton Stimpson <clinton at elemtech.com>
> wrote:
>
>
> Can you key off the existence of a pushurl?
> But I also wonder how this would keep the hooks updated?
>
>
> We could possibly be clever and do a little regex to check for the git at form of the url/pushurl. I hadn't considered being that sneaky, but it sound
> like a viable approach and would ease the dashboard pain.
>
> Marcus
>
>
> On Thursday, June 17, 2010 02:13:37 pm Marcus D. Hanwell wrote:
> > On Thu, Jun 17, 2010 at 4:06 PM, Moreland, Kenneth <
> kmorel at sandia.gov>wrote:
> > >  That’s a good point about CMake modifying the source tree, but I think
> > >
> > > this is one of those cases we should let the rule slide.  In this case
> we
> > > are installing what, IMHO, git should be pulling for us.  Although the
> > > Wiki says its optional, it really should be enforced for anyone who
> > > makes any commit to any repository.
> >
> > We came to a similar conclusion in Titan, but I am not sure about letting
> > the rule slide. This is new territory though, and it is just my take
> >
> > > I’m less thrilled about the “error if not installed” option because it
> > > still pushes the responsibility back on every developer.  It could also
> > > wreck havoc on the dashboards as there will be a delay in getting
> someone
> > > to fix the warning.  But if that is the general consensus, it’s way
> > > better than what we have now, which is nothing.  If that is the path we
> > > choose to
> > >
> > > follow, then I would hope that the following could be be features:
> > >    - CMake be very insistent about installing the hooks.  It should not
> > >    be easy to miss or ignore the error.
> > >    - The error should give clear instructions on how to install the
> > >    hooks.
> > >
> > >     It’s annoying to have to find it in the Wiki every time.
> > >
> > >    - The check should also look for any updates to the hooks in
> addition
> > >    to just seeing if they are installed.  One of the problems I run
> into
> > >    is that even though I try to be diligent about installing hooks, I
> > >    miss changes pushed to the repository.
> > >    - The check should turn itself off if not run in a git repository.
>  A
> > >    user who downloaded the source from the web would never be able to
> > >    satisfy the requirement.
> >
> > The checks in Titan have all but the third feature. That would be a
> > valuable general addition though, and I think there is some code floating
> > around that could help us to accomplish this. It would be good to hear
> how
> > others feel about this, but we should certainly be making these things as
> > easy as possible for our developers. I will see what our software process
> > type people think - Brad, Dave, Bill?
> >
> > Marcus
> > --
> > Marcus D. Hanwell, Ph.D.
> > R&D Engineer, Kitware Inc.
> > (518) 881-4937
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100629/cbba5ce7/attachment.html>