Closed Bug 594930 Opened 9 years ago Closed 6 years ago

Release automation should pushsnip automatically

Categories

(Release Engineering :: Release Automation: Other, defect, P4)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: joduinn, Unassigned)

References

Details

(Whiteboard: [release][automation][postrelease])

Attachments

(2 files)

As part of release automation, once we get a formal "go to pushsnip" from rel-drivers, automation should:

> - wait for formal "go"
> - pushsnip to "beta" if needed
> - pushsnip to "release" if needed
...as well as handle pushsnip to "betatest" and "releasetest"
Blocks: 594435
Priority: -- → P5
Hardware: x86 → All
Whiteboard: [release][automation]
(In reply to comment #0)
> > - wait for formal "go"
> > - pushsnip to "beta" if needed
> > - pushsnip to "release" if needed
> ...as well as handle pushsnip to "betatest" and "releasetest"

I'd like to see the automation do the following:

* backupsnip (need to modify script to provide some output?)
* push to the test channel (betatest or releasetest)
* run automated Mozmill update tests against test channel (bug 498425)
* push to appropriate channel (beta or release)
test channels are already automatically pushed as part of the 'updates' builder
No longer blocks: 478420
Blocks: 627307
Blocks: 627317
Assignee: nobody → rail
Priority: P5 → P2
Not tested in staging, a first draft.

* ReleaseUpdatesFactory.getSnippetDir() and MajorUpdateFactory.getSnippetDir() logic moved to tools/lib/python
* Used Firefox-$version-build$n (and similar for MU) instead of fuzzy $date-Firefox-$version
* Added standalone builders for pushing release, beta, mu, mu-beta snippets
Attachment #505796 - Flags: feedback?(bhearsum)
Attached patch toolsSplinter Review
Attachment #505797 - Flags: feedback?(bhearsum)
Some comments:
- I'd like to see a bit of protection against somebody accidentally hitting "Force Build". Something like, bailing out unless a certain property name/value exists would be sufficient.
- ffxbld won't work for backupsnip/pushsnip, you should use ausUser from the release config
- To be superduper safe, it would be good to check that the directory exists prior to trying to run any commands
- For consistency, I'd like to see ReleaseUpdatesFactory use this for pushing test snippets rather than its current steps.
- What do you think of having a more generic builder for this, and using a property to define "action"? If you did that, you could even forego my first point.
- Mail should be sent to release-drivers 5min after the "pushsnip" completes successfully.

I assume the echo_run_remote_cmd() will be a real run_remote_cmd() at some point?
Attachment #505797 - Flags: feedback?(bhearsum) → feedback+
Comment on attachment 505796 [details] [diff] [review]
buildbotcustom changes

feedback- to this one, see previous comment.
Attachment #505796 - Flags: feedback?(bhearsum) → feedback-
Just realized another important thing: separating backupsnip/pushsnip -- we need to be able to run backupsnip well ahead of when we're going to push.
Duplicate of this bug: 632843
Priority: P2 → P3
Priority: P3 → P4
No longer blocks: 627271
Not working on this bug actively. Back to the pool.
Assignee: rail → nobody
Mass move of bugs to Release Automation component.
Component: Release Engineering → Release Engineering: Automation (Release Automation)
No longer blocks: hg-automation
We'll need this for rapid betas.
Blocks: daily-beta
With regards to the rapid betas, this trigger should be based on QA automation completing the sign-offs. Possibly use Rabbit queue here or something else, tbd.
(In reply to Lukas Blakk [:lsblakk] from comment #12)
> With regards to the rapid betas, this trigger should be based on QA
> automation completing the sign-offs. Possibly use Rabbit queue here or
> something else, tbd.

And by based on, I mean that as one option since while this will be true for rapid betas it will not be for all types of releases. Some will required different triggers (email to rel-drivers, for example).
It's notable that this goes away when Balrog is in production, too, where "pushsnip" is replaced with a web ui.
Whiteboard: [release][automation] → [release][automation][postrelease]
Product: mozilla.org → Release Engineering
I don't think it's worth doing this at this point because the Balrog is coming. (https://wiki.mozilla.org/Balrog)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.