1052201 - Move hghooks repository into version-control-tools

Status: RESOLVED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Gregory Szorc [:gps]]

I am proposing that we import the hghooks repo (https://hg.mozilla.org/hgcustom/hghooks/) into the version-control-tools repo (https://hg.mozilla.org/hgcustom/version-control-tools/) as a subdirectory with full history and update our system tooling (https://github.com/bkero/puppet-module-hg) to deploy hghooks from version-control-tools.

Benefits:

* version-control-tools has a testing framework that can run tests on multiple versions of Mercurial and can perform code coverage tests
* version-control-tools is installed by `mach mercurial-setup` and is used by clients today. Having the hooks in the repository will more easily enable us to run the same hooks and code paths on both client and server
* version-control-tools has the beginnings of development and test environments that mimic production. This lowers the barrier to change and allows hooks to be updated easier.

The way I see this playing out is as follows:

1) Import hghooks into version-control-tools and wipe out tip on old hghooks repo to point to new location (like https://hg.mozilla.org/users/tmielczarek_mozilla.com/bzexport/rev/ccdd4e552096)
2) Modify the server tooling to install hghooks by cloning version-control-tools
3) Start modifying hghooks to play nice in its new home (hook up to new test harness, start writing tests, etc)

I view the migration of hghooks into version-control-tools as inevitable. I also see it as a blocker to writing better tests for hghooks. And I view writing better tests for hghooks as a prerequisite to upgrading the server (we should have test coverage of the hooks before we upgrade and hope for the best).

If bkero or fubar sign off on this from the server management side, I'd be more than happy to perform the import ASAP. Needinfo them for that sign-off.

There was some earlier discussion of this in bug 968958. Largest concern is old SHA-1 won't be valid in the new repo. However, my bzpost extension will update the old bugs when the imported changesets are pushed to version-control-tools ;)

Comment 1

[Kendall Libby [:fubar] (he/him)]

Nothing in puppet installs or updates hooks automagically, so it's only a matter of updating our documentation. Do eet.

Comment 2

[Gregory Szorc [:gps]]

https://hg.mozilla.org/hgcustom/hghooks/rev/62eddffd848d

Comment 3

[Gregory Szorc [:gps]]

This is done.

bzpost died part way through sending the new version-control-tools changeset URLs to the old bugs because of an apparent bug in Bugsy (the Python library talking to Bugzilla). Oh well. I can finish the process later if people care.

Comment 4

[Ed Morley [:emorley]]

(In reply to Kendall Libby [:fubar] from comment #1)
> Nothing in puppet installs or updates hooks automagically, so it's only a
> matter of updating our documentation. Do eet.

Shall I file another bug for that + updating the hgrcs, or has it already been done? :-)

Comment 5

[(no longer active)]

For the record, moving repos this way is pretty disruptive.  In the future at least a bit of an advance notice to the folks who have committed code to the repo would be appreciated.

Comment 6

[Kendall Libby [:fubar] (he/him)]

(In reply to Ed Morley [:edmorley] from comment #4)
>
> Shall I file another bug for that + updating the hgrcs, or has it already
> been done? :-)

docs are updated. no hgrcs need to be changed.

Comment 7

[Gregory Szorc [:gps]]

(In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #5)
> For the record, moving repos this way is pretty disruptive.  In the future
> at least a bit of an advance notice to the folks who have committed code to
> the repo would be appreciated.

I'm sorry about that Ehsan. I did perform a basic look at my bugmail and didn't see any in-flight work being done on hooks and I figured this change wouldn't be too disruptive. I guess I missed something :/