372447 - Add relic as a Mercurial pre-commit hook

Status: RESOLVED INCOMPLETE

(Developer Services :: Mercurial: hg.mozilla.org, enhancement, P3)

Description

[Patrick Fey]

relic is a Python script (mozilla/tools/relic), that is used for relicensing. It can also check, if files do have proper Mozilla (tri-)license information. The mission is to add this script as a Tinderbox/Buildbot test to easily detect license info regressions.

Ideally, we'd run it over the entire source tree trunk - but I'm not sure any of the tinderboxes actually pull that. Even if not, we could run one on a Firefox tinderbox and one on a Thunderbird one, and see if that was OK.

Probably we need to add a special mode to relic. The question is, what kind of test framework would be the best suited for our needs and what kind of output will this test framework expect from relic?

Comment 1

[Gervase Markham [:gerv]]

rhelmer: who would be the best person to answer the questions posed here in the initial comment?

Gerv

Comment 2

[Robert Helmer [:rhelmer]]

(In reply to comment #1)
> rhelmer: who would be the best person to answer the questions posed here in the
> initial comment?

I'd like to give robcee a chance to respond, fwiw I don't think this should run on a build machine because (a) build machines don't check out all of the source and (b) we want to optimize for turnaround time.

As for reporting, you'd need to print your results in a tinderbox server scrapable format:

TinderboxPrint: no license on n files

Both buildbot and tinderbox client report to tinderbox server, so you'd want to do that so numbers show up on tinderbox (just as test output like Tp, Ts, etc. do on http://tinderbox.mozilla.org/Firefox/ for example).

So, make a script that does what you want and prints the desired results prepended by "TinderboxPrint: ". The next step is to find a place to run this.

Comment 3

[Gervase Markham [:gerv]]

If we want robcee to respond, we need to CC him :-)

Gerv

Comment 4

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #3)
> If we want robcee to respond, we need to CC him :-)

That's true. I'm not magical, like Gavin. :)

It should be fairly easy to add this to a buildbot machine. I believe I even have a suitable piece of hardware for it. As rhelmer suggests, you'll want to make sure relic outputs on stdout in some easy-to-parse format. If should probably be verbose and have a line for each file you're testing with PASS or FAIL messages at the beginning of the line.

I guess the easiest thing for me to do is check it out and try it.

Comment 5

[Gervase Markham [:gerv]]

Rob: Sure, check it out from CVS and have a go. I don't really want to output 20,000 PASS lines if I can avoid it. It seems wasteful. Why don't we just output the FAIL lines?

Gerv

Comment 6

[Gervase Markham [:gerv]]

robcee: any progress here?

Gerv

Comment 7

[Rob Campbell [:rc] (:robcee)]

it's still on my todo list, but have a few other high-priority items ahead of it. If this is a critical piece we can raise it with timr and schrep next week.

Comment 8

[Gervase Markham [:gerv]]

I doubt we could really call it "critical". But it's great that it's still on your list :-)

Gerv

Comment 9

[Rob Campbell [:rc] (:robcee)]

Yeah, don't worry. I haven't forgotten about it. :)

Comment 10

[Gervase Markham [:gerv]]

robcee: Any news here? Having this would save me having to rerun it every so often and fix a bunch of problems.

Gerv

Comment 11

[Rob Campbell [:rc] (:robcee)]

nothing to report. Still on my list, but about nested about 5 items down.

Comment 12

[Gervase Markham [:gerv]]

Moving to Release Engineering at robcee's suggestion.

Gerv

Comment 13

[Gervase Markham [:gerv]]

Implementation strategy:

- This test is run regularly, like any other unit test
- It is run against mozilla-central and trunk CVS
- If it breaks, the tree turns orange, like any other unit test
- The developer who checked in the duff headers is responsible for fixing them
- If they just use the standard boilerplate like they are supposed to, they 
  won't have any problems :-)

I'd need to go through and fix all the current problems before switching this on - but I don't want to do that if it'll all just regress again. (I've been round that circuit several times, hence this bug.) So let's get it all ready to go, and I'll fix it.

Gerv

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

I think this would be a great thing to do in a Mercurial checkin hook rather than after the fact, given CVS is getting used less and less. What do you think Gerv ?

Comment 15

[Gervase Markham [:gerv]]

Nick: are those synchronous or asynchronous? To run this over the whole tree takes ten to fifteen minutes. Or would it just run over the changed files? Are you suggesting a pre-checkin hook (can't check in if it's not right)? That would certainly do the job of enforcement...

Gerv

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

Gerv, I was imagining a hook that enforced proper licensing only on newly added files, followed by a final round of fixes from yourself to bring the repo up to the required standard. 

Can't say that I've written an hg hook before, but the above looks possible from hg documentation. eg the template file_adds will return a list of added files for a given changeset, try this with a recent mozilla-central clone
 hg log -r 10119fe2af2b3f3b1df7d585a38becc90ff8d67a --template "{file_adds}\n"
You should get two additions in toolkit/mozapps/update/test/unit/ back. If you can then get hg to export those files to disk or stdout then I imagine relic could be used to test them. The pretxncommit hook maybe the most useful.

Comment 17

[Gervase Markham [:gerv]]

nthomas: it would need to be run over both newly-added and changed files, because people somtimes add themselves to the Contributors: line and mess things up. But that sounds like a great idea.

Who are our mercurial experts? I'd expect the hook to shell out to relic rather than try and turn relic itself into a hook script. 

Gerv

Comment 18

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 19

[Chris Cooper [:coop] (he/him)]

Aravind: you've touched hg hooks before, so maybe you can point us at the right person to get this hook written/tested/deployed.

Comment 20

[Chris Cooper [:coop] (he/him)]

Assigning to IT to investigate the feasibility of using an hg hook for relic.

Comment 21

[Gervase Markham [:gerv]]

Using it as a pre-commit hook is a great idea! If you can just tell me what parameters such a hook takes and what return value it needs for success or failure, I can either modify relic or create a wrapper script to do the right thing.

Gerv

Comment 22

[Aravind Gottipati [:aravind]]

Sorry, just getting to this bug.. The right component for all kinds of hg customizations is Mozilla.org-Hg:Customizations, moving this bug there were Ted and other folks that do this sort of stuff can develop and comment on how/where they want it to hook into the system.

Comment 23

[Dirkjan Ochtman (:djc)]

Easiest way is probably to create a Python pretxncommit hook (see http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html for different hook types). Take the node, then use the Mercurial API (http://mercurial.selenic.com/wiki/MercurialApi) to figure out changed files and pass that on through relic (presumably there's a nice function in there you can call). Ask for help in #hg on irc.mozilla.org or #mercurial on freenode if you're not getting the API to work. Rough approximation of required code:

def hook(ui, repo, node, **kwargs):
    ctx = repo[node]
    for fn in ctx.files():
        src = ctx[fn].data()
        relic,process(src)

Comment 24

[Gregory Szorc [:gps]]

Closing 4 year old bug with no activity. Reopen or file a new bug if you would like movement on this.