[vtk-developers] Auto install git hooks

[Moreland, Kenneth]

That sounds pretty good to me.

-Ken


On 6/29/10 2:27 PM, "Marcus D. Hanwell" <marcus.hanwell at kitware.com> wrote:

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 <http://marcus.hanwell@kitware.com> > wrote:

On Thu, Jun 17, 2010 at 4:40 PM, Clinton Stimpson <clinton at elemtech.com <http://clinton@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@ 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






   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100629/a02b2c23/attachment.html>