Closed Bug 1465799 Opened Last year Closed Last year

Windows build bustages USE_STUB_INSTALLER is not specified in the environment when Gecko 62 merges to Beta on 14-06-2018

Categories

(Release Engineering :: General, defect)

defect
Not set

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox60 unaffected, firefox61 unaffected, firefox62+ verified)

VERIFIED FIXED
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- unaffected
firefox62 + verified

People

(Reporter: apavel, Assigned: Callek)

References

Details

Attachments

(3 files, 1 obsolete file)

Hrm this is a tricky one, I didn't expect to break simulation pushes but this won't break on the merge to beta (because it keys off taskcluster project, which doesn't have it enabled on try...)

I'm not sure what the right solution is offhand right now.
Ryan said he'd fold this into the uplift-sim patch if it works.

This should fix it for now (We may need to adjust in a bit)
Assignee: nobody → bugspam.Callek
Flags: needinfo?(bugspam.Callek)
Attachment #8983176 - Flags: review?(ryanvm)
Attachment #8983174 - Attachment is obsolete: true
Andrei, please include this patch in your next round of uplift simulations to see if it helps with this issue. Thanks!
Flags: needinfo?(aciure)
OK, we will, thanks.
Flags: needinfo?(aciure)
Duplicate of this bug: 1467314
Callek, there's a related issue on maple where the l10n nightly jobs fails,
 https://treeherder.mozilla.org/#/jobs?repo=maple&revision=0fdbae4678f3e71479c6956124723e48352937af&selectedJob=182463324
but not the en-US nightly. Is there another maple-specific hack we can land there ?
(In reply to Nick Thomas [:nthomas] (UTC+12) from comment #8)
> Callek, there's a related issue on maple where the l10n nightly jobs fails,
>  https://treeherder.mozilla.org/#/
> jobs?repo=maple&revision=0fdbae4678f3e71479c6956124723e48352937af&selectedJob
> =182463324
> but not the en-US nightly. Is there another maple-specific hack we can land
> there ?

Yes, we can fix this on maple-specific with patches to:

https://dxr.mozilla.org/mozilla-central/source/taskcluster/ci/build/windows.yml#639
and
https://dxr.mozilla.org/mozilla-central/source/taskcluster/ci/build/windows.yml#269
Flags: needinfo?(nthomas)
I thought that at first too, but when I looked more closely on maple
* win32 en-US nightly ends up with USE_STUB_INSTALLER=1 in the env, is green and produces a stub
   https://tools.taskcluster.net/groups/ao2WmlM3S5G2HMSq76-qWg/tasks/elY6M1vSSGmc9tGdlAZhSw/details
* win32 *l10n* nightly doesn't have the env var, and is red
   https://tools.taskcluster.net/groups/ZtKvjRK3Q7OuxTS4ipfqFw/tasks/DB7-mhsnTQeDARPydzXoZQ/details

AIUI your links are for the en-US nightlies, so I'm not sure why they don't hit the 'default: false' on maple and have bustage. We have 'project: maple' in parameters.yml for both the push and promote decision tasks. 

And it looks like release l10n doesn't inherit use-stub-installer from the nightly job like we do for m-c, so perhaps there really is an issue with release promotion which needs fixing for 62.
Flags: needinfo?(nthomas)
Attachment #8983176 - Flags: review?(ryanvm)
Fixes https://bugzilla.mozilla.org/show_bug.cgi?id=1465799#c11 specifically the fact that USE_STUB_INSTALLER is leaked through other tasks even though its not actually specified for other tasks
Attachment #8985686 - Attachment description: Bug 1465799 - Prevent worker environment leaking from one task to the next. r=dustin → Bug 1465799 - Makes sure that we don't check for a truthy stub-installer value until after resolving keyed by r=dustin
(In reply to Cosmin Sabou [:CosminS] from comment #14)
> The issue still persists with the patch applied:
> https://treeherder.mozilla.org/logviewer.
> html#?job_id=183584809&repo=try&lineNumber=1537
> 
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=536226982a00fd69ebccf2834cea87ae152baed1&filter-
> resultStatus=testfailed&filter-resultStatus=busted&filter-
> resultStatus=exception&filter-
> searchStr=200978e1058ca08fcd06b81dde0645758c43cab2&selectedJob=183584809

https://bugzilla.mozilla.org/attachment.cgi?id=8983176 is the patch that would have been necessary this other patch is for a different (but similar) issue.
This is actively burning Win32 builds on Beta62 now.
Flags: needinfo?(bugspam.Callek)
Comment on attachment 8985686 [details]
Bug 1465799 - Makes sure that we don't check for a truthy stub-installer value until after resolving keyed by r=dustin

Dustin J. Mitchell [:dustin] pronoun: he has approved the revision.

https://phabricator.services.mozilla.com/D1671
Attachment #8985686 - Flags: review+
Flags: needinfo?(bugspam.Callek)
Comment on attachment 8986248 [details]
Bug 1465799 - Set expectations for stub installer to true on beta/release because we always set update channel as such on these branches. r=aki

Aki Sasaki [:aki] has approved the revision.

https://phabricator.services.mozilla.com/D1708
Attachment #8986248 - Flags: review+
Pushed by Callek@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7f07e22575ae
Makes sure that we don't check for a truthy stub-installer value until after resolving keyed by r=dustin
https://hg.mozilla.org/integration/mozilla-inbound/rev/bf1d08ea54a8
Set expectations for stub installer to true on beta/release because we always set update channel as such on these branches. r=aki
Pushed by Callek@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/778e2a00786e
Makes sure that we don't check for a truthy stub-installer value until after resolving keyed by r=dustin
https://hg.mozilla.org/integration/mozilla-inbound/rev/36b51dda5abe
Set expectations for stub installer to true on beta/release because we always set update channel as such on these branches. r=aki
Flags: needinfo?(bugspam.Callek)
See Also: → 1474628
You need to log in before you can comment on or make changes to this bug.