release_history object should be populated for desktop only

NEW
Assigned to

Status

Release Engineering
General Automation
16 days ago
7 days ago

People

(Reporter: rail, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 days ago
I just realized that we populate the `release_history` object for all kind of nightly decision tasks, including Android.
(Assignee)

Comment 1

16 days ago
Created attachment 8925506 [details] [diff] [review]
nightly_desktop.diff

Simon, what do you think about this change? Also, before I submit it for review, do you mind if I rename `populate_release_history()` to something like `populate_nighlty_release_history()`.
Attachment #8925506 - Flags: feedback?(sfraser)
Comment on attachment 8925506 [details] [diff] [review]
nightly_desktop.diff

I'd update the comment as well, but it looks good. Are we worried about cases where people trigger a nightly for a specific platform? 


desktop_nightlies = [
    'nightly_linux',
    'nightly_macosx',
    'nightly_win32',
    'nightly_win64',
    'nightly_desktop',

]
if parameters.get('target_tasks_method') and parameters.get('target_tasks_method') in desktop_nightlies:
Renaming the function is a good idea. The TC folks may prefer us renaming the mach command as well, as release_history is too broad.
(Assignee)

Comment 4

16 days ago
Ah, good point. I wonder if we can distinguish nightlies by product...
There doesn't seem to be an easy way of doing that.  The --force-run parameter makes it through taskcluster/taskgraph/cron/* as job_name, but that ends up only in the human readable fields, the scopes, and the routes. It seems that we either update .taskcluster.yml to add it to the parameters, or do the long-winded check.
Should we just go ahead with checking for nightly_desktop and seeing if it breaks things?
You need to log in before you can comment on or make changes to this bug.