improve task selection and setup of nightly-build-tasks action on try
Categories
(Release Engineering :: General, enhancement, P3)
Tracking
(firefox154 fixed)
| Tracking | Status | |
|---|---|---|
| firefox154 | --- | fixed |
People
(Reporter: bhearsum, Assigned: bhearsum)
References
Details
Attachments
(5 files)
There's a couple of things less than ideal at the moment:
- A number of tasks don't run at all (eg: balrog, beetmover)
- Release history is generated against production balrog rather than stage, which makes it impossible to test sequential nightlies
|
Assignee | |
Comment 1•20 days ago
|
||
I'm not certain on why these are so explicitly included, but these days tests never end up running as part of nightly graphs, because they run on the on-push graphs. This change has no effect on main, but prevents tests from running as part of nightly build tasks on Try, where they're never wanted.
This patch alone has no effect, but downstream changes in this stack will be making changes that would cause tests to be included when running the nightly-build-tasks action on Try, which would be undesirable.
A couple of theories as to why this are here are:
- https://phabricator.services.mozilla.com/D16580, where it's unclear if this was intentional to pull them in in the first place. That change talks about wanting
bouncer-locationsrunning, which presumably didn't haveshipping-productset at the time, and tests were pulled in (and documented as being pulled in, without justifying it) as a side effect - I have a vague memory that pre-https://bugzilla.mozilla.org/show_bug.cgi?id=1614970, we may have only been running PGO builds on actual nightly builds, and thus wanted to run tests on them.
|
|
Assignee | |
Comment 2•20 days ago
|
||
These days, all of the tasks that run as part of the nightly graph have this set, so this is a no-op change that corrects what appears to be a relatively lazy workaround introduced in https://phabricator.services.mozilla.com/D16580.
|
|
Assignee | |
Comment 3•20 days ago
|
||
These look-ups are done in Balrog, and the server we look them up in is based on the branch given. When I first implemented this action, Balrog stage was in a sorry state, and there were no try releases to be found there. I was too lazy at the time to fix this up, and instead ended up relying on looking up production nightlies in production Balrog. This worked to a degree, except that it means there's no way to test subsequent nightlies on Try, which makes testing certain types of changes to partial generation or update verification impossible.
Since I'm making such changes right now, I've made an effort to populate at least one try nightly in Balrog stage, so we can adjust this action to point in the correct place. As long as this (or at least one future) try nightly continues to exist this action should continue to work fine.
|
|
Assignee | |
Comment 4•20 days ago
|
||
Many tasks set run-on-projects to integration, release, etc. This causes these tasks not to be considered target tasks for Try by target tasks methods such as nightly_desktop. Up until now, this hasn't mattered: they've been pulled in explicitly by try selectors or release promotion target tasks methods.
The relatively new nightly-build-tasks action relies on other target tasks methods for task selection, however (and intentionally so to keep it in line with production nightlies). When using this action, we're currently missing many task, most notably beetmover and balrog tasks, which are needed to properly test partial generation and update verification.
I expect this change to be a no-op, except when tasks are created with the nightly-build-on-try action.
|
|
Assignee | |
Comment 5•20 days ago
|
||
This logic is currently wrong, and both generates release history when limit_product is any non-empty value at all, and fails to generate it when it's empty (meaning we want desktop nightlies).
|
||
Updated•20 days ago
|
|
||
Comment 7•16 days ago
|
||
| bugherder | ||
|
||
Updated•14 days ago
|
Description
•