Closed Bug 843606 Opened 11 years ago Closed 11 years ago

Roll out prevent_broken_csets hook on mozilla-aurora

Categories

(Developer Services :: General, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: justin.lebar+bug, Assigned: bkero)

References

Details

In bug 843081 I wrote a new hg pretxncommit hook, prevent_broken_csets.py.

https://hg.mozilla.org/hgcustom/hghooks/rev/88aa117ff487

We need to prevent these broken changesets everywhere except tryserver, where they don't matter.

Can you please roll this hook out to our hg servers?  These hooks are somewhat difficult to test locally, and this hook in particular is difficult to test because I haven't figured out how to create one of these busted changesets on demand.  So if we can roll it out gradually, that would be probably be prudent.
Once we roll out this hook, we'll also need to update the merge docs; see bug 843081 comment 9.
Justin,

Can you pick ONE repo to roll this out to at first. Can we then test this extensively and make sure things don't break before we roll this out everywhere?
Absolutely.  But I'm not sure which one repository to pick.  We want something that various people commit to, since this hook has to do with different hg versions.  But we don't want something that, if we break things, we'll block lots of people.

Perhaps we should start with mozilla-aurora.  If that looks good, we can move to mozilla-central (which is mostly managed by sheriffs, who can handle things going wrong), and finally to m-i.
Summary: Roll out prevent_broken_csets hook on all trees except try → Roll out prevent_broken_csets hook on mozilla-aurora
Have you double-checked that qimporting and qfinishing fixes up the changesets?
(In reply to Siddharth Agarwal [:sid0] from comment #4)
> Have you double-checked that qimporting and qfinishing fixes up the
> changesets?

No, I'd put that pretty far down on my list of possibilities...
> No, I'd put that pretty far down on my list of possibilities...

Hm, "I'd" is ambiguous.  I meant I /had/, not I /would/.
That's what you suggest doing in the hook, right?
(In reply to Siddharth Agarwal [:sid0] from comment #7)
> That's what you suggest doing in the hook, right?

Yes, although I suggest doing so after upgrading to 2.5.1, which shouldn't strictly be necessary, but in any case should definitely not have this problem.  A patch file can't even encode the information necessary to cause the bug, right?

Anyway, you are absolutely right, I should test that qimport && qpop works.
Git style patch files do contain copy information.
And merely upgrading to 2.5.1 won't fix broken changesets. You need to actually regenerate them somehow.
(In reply to Siddharth Agarwal [:sid0] from comment #10)
> And merely upgrading to 2.5.1 won't fix broken changesets. You need to
> actually regenerate them somehow.

Right, but that's what qimport && qfin is for; at least, that was my theory.  Unless, as you fear, the patches could somehow be tainted.
Looks like you were right, Sid; I needed to qimport && qpop && qpush && qfin.  Otherwise hg doesn't recreate the changeset from the patch.

Thanks for bugging me about this.

I'll update the hook.
It would be great if you checked one more thing: whether your instructions work if [diff] git = True is set in .hgrc.
(In reply to Siddharth Agarwal [:sid0] from comment #14)
> It would be great if you checked one more thing: whether your instructions
> work if [diff] git = True is set in .hgrc.

Yes, that was set last night.
Ben, can we roll this out only to mozilla-aurora? Thanks!
Assignee: server-ops-devservices → bkero
I've enabled this for mozilla-aurora. Let's see if the universe ends.
Nobody's reported any horrific failures yet. Closing this out. Let me know in the other bug if you'd like me to roll it out to more repos.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Let's roll it out and see what happens!  I'll file additional bugs.
Blocks: 846953
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in before you can comment on or make changes to this bug.