hook_versioncontrol_git_refs_updated() is going away, implement the new one

@sdboyer++, thanks for the patch and the work on this.

Could you inform us about the deployment timeframe, so we can plan accordingly?

I'm assuming this is a major release upgrade for versioncontrol_git ... am I correct?

And if so, do we want this to be a major on the PIFT side of things as well? I don't believe anyone else is actively using PIFT; but this is a bit of a major change in operation. (Thoughts, Randy?)

I don't believe PIFT is used anywhere else. @boombatower would know.

Since the patch works with either the old or the new hook, there's nothing to force us to do a major version upgrade, unless we want to lose the old hook.

Yeah, I was assuming we would need to swap hooks ... but if the new hook replaces the old one in versioncontrol_git, then we should be fine keeping both.

Patch is going to need some cleanup though ... it's still referencing the '$refs' variable which was part of the original function declaration. I'm digging into it now.

@sdboyer, the problem with the old hook was that there wasn't any reasonable way to test. Do you have any suggestions for the present? How can we validate the patch here with an experiential test?

Updated patch. Removed array_keys($refs) and replaced with $branch_names.

Committed to 6.x-2.x (commit e73db34).

Patch rolled into PIFT release 6.x-2.8.

As long as the infra team can guarantee that only one of the two hooks (hook_vcs_git_refs_updated and hook_vcs_event_arrival()) will be in operation at any given time, then this should be safe for update/deployment on drupal.org.

As rfay mentioned above, we have no way of validating this patch in our dev environments. I don't foresee any issues, but be aware that this is going in blind.

Thanks for the prompt response on this!

I'm not sure what services are required for testing. @rfay: Could the old gitdev server (now git6site) do for testing?

I'm happy to work this into the test routine that sdboyer and I have going if it's feasible and I know what's required.

I believe that, for testing, we would need a d.o staging site linked to a git site through which we could trigger the commit hooks ... and some way to enable and disable this linkage on demand. We wouldn't really want to queue every commit, especially if linked to a staging site being used for git development as well.

That said, we've done without this capability to date; and while it would be a great thing to pursue in the future, I wouldn't position it as a pre-requisite in this particular case.

A test script to invoke the hook with reasonable and understood parameters would be a decent workaround.

If this gets tested in *some* context before deployment, I'm ok with it. Or if we're just really ready to back it out :-)

Please make sure we're completely aware of when deployment happens so we can monitor the results.

Deployed PIFT 6.x-2.8 tonight, to see if that might be part of why the Drupal HEAD branch test has not run since July 2nd.

Of course, other project branch tests *have* run since then, so this may not be related.

sdboyer/eliza411: Has the hook_versioncontrol_git_refs_updated() swap actually happened yet?

Looks like some contrib projects are queuing, but haven't seen a commit-initiated core test request come through yet.

Looks like I missed the last step on the deploy ... should be deployed now, and ready for a verification test.

I guess the problem is the wrong name in the hook implementation, here a patch against mainline.

PS: I am running to document the hook on vcs api :-p

I guess we should just deploy it then?

But what about a simple little watchdog at the top that says what's going on? IMO it's critical. SOME kind of instrumentation. It would also (if we include the contents passed in) give us a way to create a testing utility.

OK, now 6.x-2.9 is deployed with #19