release repacks on esr failing because TASKCLUSTER_PROXY_URL not set in env
Categories
(Release Engineering :: General, defect)
Tracking
(firefox-esr68 fixed)
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | fixed |
People
(Reporter: jlund, Assigned: nthomas)
Details
Attachments
(1 file)
likely fallout from missing uplfits to esr68 from tc migration work
e.g. https://firefoxci.taskcluster-artifacts.net/WxhN7pCfQdSW8TEjD_7rTA/1/public/logs/live_backing.log
planning to ignore given time of day. Will try and get non partner tasks finished so QE can test.
|
Assignee | |
Comment 1•6 years ago
|
||
There's a couple of problems here
1, release-partner-repack-win32-shippable is failing because it's trying to repack stub installers, which we don't produce on ESR. The partner config for mozillaonline was moved to a public repo, and it looks like the esr branch got the contents of the master. I'll open a PR for mkaply to merge for this. We can likely respin for this within 24 hours
2, Missing TASKCLUSTER_PROXY_URL in release-partner-repack-repackage jobs, when they try to fetch upstream target.zip and setup.exe artifacts. Not sure where this comes from, Aki's suggestion about missing GCP migration patch sounds likely.
|
|
Assignee | |
Comment 2•6 years ago
|
||
(In reply to Nick Thomas [:nthomas] (UTC+13) from comment #1)
1, release-partner-repack-win32-shippable is failing because it's trying to repack stub installers, which we don't produce on ESR. ...
|
|
Assignee | |
Comment 3•6 years ago
|
||
2, Missing TASKCLUSTER_PROXY_URL in release-partner-repack-repackage jobs, when they try to fetch upstream target.zip and setup.exe artifacts. Not sure where this comes from, Aki's suggestion about missing GCP migration patch sounds likely.
Haven't got to the bottom of this, but one obvious difference between 68.2.0esr and 68.3.0esr task definitions (cjkIHH4HRNahtlB5zRJ-IQ vs ZQPBTI7NQieYOpz5IYPrCg) is we don't have taskclusterProxy in features any more.
The code in the repackage_partner transform is still setting True, but something must be reverting/not acting on that later. Do you have any insight on this Tom ?
|
||
Comment 4•6 years ago
|
||
There are couple of things going on. In 0fe123847638, the mozharness job type started unconditionally setting job['worker']['taskcluster-proxy'] based on job['run']['taskcluster-proxy'], which overrides the setting from the repackage_partner transform. We can fix that by moving that setting to the run block.
I noticed we have the same code on central. However, we repackage on linux there, and unconditionally enable the proxy there.
It looks like there is also support on central for turning on the proxy based on fetches here, but it looks like that would be overridden by mozharness, and then turned on unconditionally later.
|
|
Assignee | |
Updated•6 years ago
|
|
|
Assignee | |
Comment 6•6 years ago
|
||
|
||
Updated•6 years ago
|
|
|
Assignee | |
Comment 7•6 years ago
|
||
Comment on attachment 9111804 [details]
Bug 1599341 - fix windows repackage jobs for partner repacks on esr68, r=aki, a=release DONTBUILD
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: This fixes some ESR68 specific bustage in creating partner repacks, specifically when creating the windows installers for MozillaOnline.
It would land on default only, and then I would respin the partner repacks without needing to do the regular builds. It will also fix 68.3.0esr build3 if we do one. If we ship build2, and later relbranch for a 68.3.1, it would be helpful to branch from when this lands, or we'll need to reland on the relbranch.
- User impact if declined: No windows repacks for MozillaOnline to ship.
- Fix Landed on Version: N/A
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It only affects two jobs in the task graph, adding re-enabling the taskclusterProxy feature that we lost in migrating to the new TC instance.
- String or UUID changes made by this patch:
|
|
Assignee | |
Comment 8•6 years ago
|
||
Comment on attachment 9111804 [details]
Bug 1599341 - fix windows repackage jobs for partner repacks on esr68, r=aki, a=release DONTBUILD
Landed by sheriffs at my request, under the a=release policy we've used previously:
https://hg.mozilla.org/releases/mozilla-esr68/rev/91683264ef7c1dfd4db8985b5387cfc9c19189b8
|
||
Comment 9•6 years ago
|
||
| bugherder uplift | ||
|
|
Assignee | |
Comment 10•6 years ago
|
||
Off-cycle respin done on graph https://firefox-ci-tc.services.mozilla.com/tasks/groups/XWFhXu_bQdWHLzJtFRDIZA
Files are in
https://archive.mozilla.org/pub/firefox/candidates/68.3.0esr-candidates/build2/partner-repacks/mozillaonline/esrWinFull/v201911282159/
https://archive.mozilla.org/pub/firefox/candidates/68.3.0esr-candidates/build2/partner-repacks/mozillaonline/esrOther/v201911282159/
Description
•