Let's deploy hgtool (and its dependencies) on the build/test slaves in /usr/local/bin or equivalent. Then we can use it to make sure our tools checkouts are up to date withtout the expensive clobber/re-clone we do right now.

I thought we were going to try to get rid of tools altogether (which I believe we can).

For tests we can get rid of tools altogether (another bug!), but plenty of build stuff relies on tools.

standalone version of hgtool.py

going to rely on this for mozharness's hgtool support

Comment on attachment 664306 [details] [diff] [review] puppet manifests for deploying standalone hgtool as per IRC, not sure about naming here...maybe tools::hgtool or utils::hgtool is a better module name?

Comment on attachment 664306 [details] [diff] [review] puppet manifests for deploying standalone hgtool Review of attachment 664306 [details] [diff] [review]: ----------------------------------------------------------------- The comment below actually sums it up - if this is the authoritative place for hgtool, then it deserves a top-level module and uncompressed sources so we can see the diffs. If not, it should be considered a package, preferably as an RPM, but at least under `packages::mozilla::hgtool`. I think that the same applies to tooltool, and that build/puppet is not the authoritative source for tooltool, but if that needs to be moved too, we should do so. ::: modules/hgtool/files/hgtool.py @@ +1,2 @@ > +#!/usr/bin/python > +### Compressed module sources ### I don't think this is a great idea. If hgtool must be distributed like this, then let's build an RPM for it. Otherwise, these files should be included in plaintext in puppet so that we'll see reasonable diffs if/when they change. That really depends on whether this is the "authoritative" copy of hgtool (in which case it should be diffable) or just a derivative copy of something in tools/ (in which case it should be packaged).

I think creating an rpm (/dmg) is overkill for this. The scripts and instructions for generating the packed version from the authoritative copy in build/tools will be added to build/tools.

(In reply to Chris AtLee [:catlee] from comment #8) > I think creating an rpm (/dmg) is overkill for this. The scripts and > instructions for generating the packed version from the authoritative copy > in build/tools will be added to build/tools. I take this back. Having an rpm will make it easier to get hgtool running _inside_ mock. I don't know if that's something we need right away or not.

Comment on attachment 664492 [details] [diff] [review] move into packages::mozilla::hgtool This looks fine to commit now; it will be an easy change to replace this with an RPM.

Works on all platforms that are on puppetagain. We still need it on Windows.

Probably not going to do this since all of machines we manage are dead or dying?