Open Bug 1256719 Opened 6 years ago Updated 2 years ago

mark releases as read only after balrog submission is complete

Categories

(Release Engineering :: Release Automation: Updates, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: bhearsum, Assigned: asilva)

References

Details

Attachments

(2 files, 1 obsolete file)

Once bug 1127875 lands, we'll have the ability mark releases as "read only" in Balrog - preventing further changes to them. This seems like a generally useful thing to do for releases that have been shipped for two reasons:
1) If we try to manually make a change to an already shipped release, we will get an error (unless read_only is unset first). This serves as a good reminder to think hard in this situation.
2) Because automation accounts won't be able to unset read_only, it makes it more difficult for an attacker that gains access to an automation account to affect real users.
++
++ from me too. It maybe easier to do this when pushing updates, since we already have a balrog script running at that point.
Priority: -- → P3
Component: Release Automation: Other → Release Automation: Updates
It's probably better to do this after submission has completed now actually - to avoid the possibility of somebody modifying it after we've run update verify.
Summary: mark releases as read only as part of postrelease → mark releases as read only after balrog submission is complete
Presumably, we'll want to have a dummy task after all the balrog tasks are done, and before update verify starts. This means that update-verify will wait until all platforms are done.
(In reply to Tom Prince [:tomprince] from comment #4)
> Presumably, we'll want to have a dummy task after all the balrog tasks are
> done, and before update verify starts. This means that update-verify will
> wait until all platforms are done.

That's a notable change; this means that Linux & Mac update verify will start later than now, since they'll block on the much slower Windows builds/repacks. I'm not sure whether or not this will increase the end to end time of the promote graph -- Windows update verify will still be the long pole, but we'll now be running ~60 update verify at once, so we may increase contention in the gecko-b-3-linux pool. This is probably an OK trade-off.
Bug 1482395 tracks automating whatsnew page work which is currently manual, and would need extra steps once the release is marked readonly.
See Also: → 1482395
(In reply to bhearsum@mozilla.com (back in 2019Q1) from comment #5)
> (In reply to Tom Prince [:tomprince] from comment #4)
> > Presumably, we'll want to have a dummy task after all the balrog tasks are
> > done, and before update verify starts. This means that update-verify will
> > wait until all platforms are done.
> 
> That's a notable change; this means that Linux & Mac update verify will
> start later than now, since they'll block on the much slower Windows
> builds/repacks. I'm not sure whether or not this will increase the end to
> end time of the promote graph -- Windows update verify will still be the
> long pole, but we'll now be running ~60 update verify at once, so we may
> increase contention in the gecko-b-3-linux pool. This is probably an OK
> trade-off.

update verify currently does a few things:
1) checks that MARs are correctly represented in Balrog (on test channels)
2) checks that MARs can be applied correctly

if we split these up, and have update-verify check that the MARs can be applied correctly, these could be fetched from TC artifacts directly, or from the candidates dir, and not rely on Balrog state.
Assignee: nobody → allan.tavares
Attached file GitHub Pull Request
Attachment #9109035 - Flags: review?(mtabara)
Attachment #9109035 - Flags: review?(bhearsum)
Attachment #9109035 - Flags: review?(mtabara) → review+
Attachment #9109035 - Flags: review?(bhearsum) → review+
Attachment #9128354 - Flags: review?(bhearsum)
Comment on attachment 9128354 [details] [diff] [review]
0001-Bug-1256719-mark-releases-as-read-only-after-balrog-.patch

Review of attachment 9128354 [details] [diff] [review]:
-----------------------------------------------------------------

This is a good start, but we need to add `- post-balrog-dummy` to the dependencies too, to make sure we don't mark as read only until after locale submission has completed.

Ideally, we'd block update verify on this new kind, but let's save that for a follow-up (I think it'll end up being fairly complicated, so let's keep things simple for now).
Attachment #9128354 - Flags: review?(bhearsum) → feedback+

New patch including the post-balrog-dummy dep.

Attachment #9128354 - Attachment is obsolete: true
Attachment #9147009 - Flags: review?(bhearsum)
Comment on attachment 9147009 [details] [diff] [review]
0001-Bug-1256719-mark-releases-as-readonly-after-balrog-s.patch

We decided to punt on this until the v2 releases API is being used in production.
Attachment #9147009 - Flags: review?(bhearsum)
You need to log in before you can comment on or make changes to this bug.