Closed Bug 677005 Opened 9 years ago Closed 8 years ago

Automated blocklist update blew away blocklist.xml

Categories

(Release Engineering :: General, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Dolske, Assigned: coop)

Details

Attachments

(1 file)

Was browsing the hg pushlog, and happened to check what got pushed...

http://hg.mozilla.org/mozilla-central/rev/6845d4b46d7a

Oops. Looks like it accidentally the whole file. :-( Indeed, it's a 0-byte file in my tree.

[Note that, at the moment, MXR's index is like a week stale, so if you check on MXR it looks like the file is still ok]

Probably also need either a test in the script to make sure it's a legit looking update, and/or a test in the tree to blow up if the update's bad?
I'm guessing the automatic update coincided with some AMO downtime or something since AMO's data looks fine right now. Can we trigger the update now to get things right in the tree again then figure out a way to avoid it in the future.

I could have sworn we used to have a check to ensure the blocklist.xml downloaded was larger than a certain size before landing.
The next automatic update will occur in just a few hours (early saturday), that said I am bumping severity.

Also for ref, suite/'s update was fine (but I know it ran at a much different time than Fx's update)

http://hg.mozilla.org/comm-central/rev/c15ed4c2c86d
Severity: normal → major
(In reply to Justin Wood (:Callek) from comment #2)
> The next automatic update will occur in just a few hours (early saturday),
> that said I am bumping severity.

Now that we have an empty blocklist in hg, the script is actually failing on that since it doesn't look like valid XML.

Someone should grab and land a new, valid version of the blocklist by hand for m-c.

Also, the script has been trying to update the blocklist for 1.9.2 for a few weeks now, but since that tree is marked as approval required, the script is failing. If we want to take a blocklist update there, we'll need someone to land the update by hand there too.
(In reply to Chris Cooper [:coop] - away until Aug 19 from comment #3)
> (In reply to Justin Wood (:Callek) from comment #2)
> > The next automatic update will occur in just a few hours (early saturday),
> > that said I am bumping severity.
> 
> Now that we have an empty blocklist in hg, the script is actually failing on
> that since it doesn't look like valid XML.
> 
> Someone should grab and land a new, valid version of the blocklist by hand
> for m-c.

Easier path forward imo, is for someone [releng perhaps] to backout the code change from this botched landing, land with DONTBUILD and then releng to manually kick a new blocklist update for m-c right after that. Will ensure that everything lands correctly.

> Also, the script has been trying to update the blocklist for 1.9.2 for a few
> weeks now, but since that tree is marked as approval required, the script is
> failing. If we want to take a blocklist update there, we'll need someone to
> land the update by hand there too.

I thought we had a=blocklist-update in the script [at least the version SeaMonkey currently uses has that.] if it was removed somehow, I'd suggest adding it back in, fwiw.
(In reply to Justin Wood (:Callek) from comment #4) 
> I thought we had a=blocklist-update in the script [at least the version
> SeaMonkey currently uses has that.] if it was removed somehow, I'd suggest
> adding it back in, fwiw.

We turned that switch off to prevent this kind of thing on 1.9.2, our mainline stable branch at the time.

Going forward, the plan is to only do blocklist updates automatically on m-c where no approval is required, and let changes get cut over to aurora/beta/release with everything else for sufficient baking.
(In reply to Chris Cooper [:coop] - away until Aug 19 from comment #6)
> (In reply to Justin Wood (:Callek) from comment #4) 
> > I thought we had a=blocklist-update in the script [at least the version
> > SeaMonkey currently uses has that.] if it was removed somehow, I'd suggest
> > adding it back in, fwiw.
> 
> We turned that switch off to prevent this kind of thing on 1.9.2, our
> mainline stable branch at the time.
> 
> Going forward, the plan is to only do blocklist updates automatically on m-c
> where no approval is required, and let changes get cut over to
> aurora/beta/release with everything else for sufficient baking.

So basically the plan is to ship releases with a blocklist that is 3 months out of date? Where was this discussed, I must have missed it.
(In reply to Dave Townsend (:Mossop) from comment #7) 
> So basically the plan is to ship releases with a blocklist that is 3 months
> out of date? Where was this discussed, I must have missed it.

No, but if the blocklist gets updated after it leaves m-c, it will be a manual process, where "manual" could mean "releng triggers the update" provided we have blocklist updates enabled on that branch.

I don't believe we've had the discussion about how late in the release game we would take a blocklist update.
Assignee: nobody → coop
This handles the proximate problem of accidentally importing an empty file as a blocklist.

I'll mail release-drivers to start a discussion about how late in the process we would accept an automated update (aurora? beta?). As noted before, we could have this blocklist update builder available on those branches for releng to trigger, i.e. it won't necessary fall to someone to update the blocklist by hand, although the script would make that trivial.
Attachment #564212 - Flags: review?(armenzg)
Comment on attachment 564212 [details] [diff] [review]
Check for 0-byte blocklists

-s checks for existence and size greater than 0.

*stamp*
Attachment #564212 - Flags: review?(armenzg) → review+
Status: NEW → ASSIGNED
Flags: needs-reconfig?
Flags: needs-reconfig?
(In reply to Chris Cooper [:coop] from comment #9)
> I'll mail release-drivers to start a discussion about how late in the
> process we would accept an automated update (aurora? beta?). As noted
> before, we could have this blocklist update builder available on those
> branches for releng to trigger, i.e. it won't necessary fall to someone to
> update the blocklist by hand, although the script would make that trivial.

Conversation started with release-drivers about this. If we decide to start auto-updating aurora, we'll file a new bug for that.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.