Failed to download "shipped-locales" when getting update paths
Categories
(Firefox Build System :: General, defect)
Tracking
(firefox-esr60 fixed, firefox-esr68 fixed, firefox70 fixed)
People
(Reporter: mhentges, Assigned: tomprince)
Details
Attachments
(1 file)
This build for "release firefox 68.0.1esr build1" is failing when attempting to load "shipped-locales" from the mozilla-unified repo.
Interestingly, it's assuming that a directory called FIREFOX_60_8_0esr_RELEASE exists in the root of the repository, but there isn't one there.
|
Assignee | |
Comment 1•5 years ago
|
||
The code is looking for the tag FIREFOX_60_8_0esr_RELEASE in mozilla-release, when it should be looking in mozilla-esr60. That is coming from here, since the version info from product-details for firefox-60.8.0esr is:
"firefox-60.8.0esr": {
"build_number": 1,
"category": "stability",
"date": "2019-07-09",
"description": null,
"is_security_driven": false,
"product": "firefox",
"version": "60.8.0"
}
Note that the category is stability, rather than esr. I think this is probably incorrect information, and it should be esr.
|
||
Comment 2•5 years ago
|
||
Looks like this is expected.
According to https://github.com/mozilla/release-services/blob/c89dcdc1a279de5aacb8812371f07807c6bcbf6f/src/shipit/api/shipit_api/product_details.py#L356, we include ESR into the "stability" category, but do some "ugly hack" when we have 2 ESR versions in parallel: https://github.com/mozilla/release-services/blob/c89dcdc1a279de5aacb8812371f07807c6bcbf6f/src/shipit/api/shipit_api/product_details.py#L362
Sounds like we move "old ESR" to "stability", when there are 2 ESR versions. I'm not sure if it used somewhere else, but it looks like the logic has been around for a longs time: https://github.com/mozilla-releng/ship-it/blob/cab01e1d587036735bfc4997a94391879623862f/kickoff/jsonexport.py#L70
|
Reporter | |
Comment 3•5 years ago
|
||
Looks like this is expected.
Does this mean that we're expected to not use our update-verification tests for this release? Won't this impact our risk of accidentally deploying an ESR that can't be updated to/from?
|
|
Assignee | |
Comment 4•5 years ago
|
||
|
|
||
Comment 5•5 years ago
|
||
I think Tom's patch should just work.
|
|
Assignee | |
Comment 6•5 years ago
|
||
(In reply to Rail Aliiev [:rail] from comment #2)
Looks like this is expected.
This seems like surprising behavior, to have the category of a version change after some time; I wonder if we should revisit that decision.
|
||
Updated•5 years ago
|
Pushed by mozilla@hocat.ca: https://hg.mozilla.org/integration/autoland/rev/678e6c3d2664 [update-verify] Use version number to determine branch, rather than product-details category; r=mhentges,rail
|
|
Assignee | |
Comment 8•5 years ago
|
||
https://hg.mozilla.org/releases/mozilla-esr60/rev/effb051638bf62adceb861294b768b450d14e9a5
https://hg.mozilla.org/releases/mozilla-esr68/rev/6cb16d2f8b7058f8f855a3db0ec21c6f8cfb79d5
https://hg.mozilla.org/releases/mozilla-esr68/rev/f5920839f310aa6e2d4b04c0a9877f67f14b00da (FIREFOX_ESR_68_0_X_RELBRANCH)
|
||
Comment 9•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
| Comment hidden (Intermittent Failures Robot) |
Description
•