857696 - add non-fastforward detection & prevention for b2g repos

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Hal Wine [:hwine] use NI!]

Many parties & partners were surprised by bug 854437, which caused downstream repos to not be able to fast forward update from Mozilla.

Preventing those surprises in the future is the goal here:
 a) ensure releng gets notified if the situation arises
 b) ensure changes do not go downstream without notification (ideally prior)

One approach to (b) is to set receive.denyNonFastForwards and receive.denyDeletes on the git.m.o repositories for which mozilla is authoritative. (thanks to mvines for the suggestion)

Comment 1

[Aki Sasaki (not active)]

Attachment: fast_forward.diff

This patch:

* moves test_push (local directory) repos before network repos in the config

* adds a _do_push_repo() called from _push_repo(), so I can break out of a loop (I had a loop inside of a loop, and I wanted to break out of the outside loop.  I didn't see a way of doing that without a helper method or a try/except)

* if pushing to a test_push repo fails, stop trying to push to any further targets for that source repo!  So if pushing b2g18 fails to local disk, don't try to push b2g18 anywhere else.  It'll go on and try to push mozilla-release later, though.

* creates the test_push repos with --shared=true, which makes them require FastForward-only pushes.

* changes the softlink to a cp, which uses more disk but allows me to move the entire conversion work_dir except the virtualenv, which is automatically recreated if blown away.  This is kind of a ride-along on the patch.


At the cost of a few gig of diskspace, we now detect non-FastForward pushes early.  Even if the network repo is set up to accept non-FastForward pushes, we can still detect if we would make such a push, and error out.

Comment 2

[Aki Sasaki (not active)]

Comment on attachment 800506 [details] [diff] [review]
fast_forward.diff

https://hg.mozilla.org/build/mozharness/rev/c0cf8ff3f13f

Comment 3

[Aki Sasaki (not active)]

Debating what to do about this bug... leave open til it's fully rolled out?  Or mark as fixed since it will be fixed once it's rolled out?

Maybe leave open for now.

Comment 4

[Jonathan Griffin (:jgriffin)]

Comment on attachment 800506 [details] [diff] [review]
fast_forward.diff

merged to production: http://hg.mozilla.org/build/mozharness/rev/312852646d08

Comment 5

[Aki Sasaki (not active)]

Bug 917071 should solve this for {gecko,gaia}.git.

Comment 6

[Aki Sasaki (not active)]

(In reply to Aki Sasaki [:aki] from comment #3)
> Debating what to do about this bug... leave open til it's fully rolled out? 
> Or mark as fixed since it will be fixed once it's rolled out?
> 
> Maybe leave open for now.

I think it'll be confusing to leave open; I'm going to mark fixed as we're planning to potentially move to the new vcs-sync system by EOQ.