Generating a taskgraph with esr60 configs[1] leads to some discrepancies. The things I've noticed are: * release-bouncer-aliases-firefox: * "aliases_entries" are busted. "firefox-esr-latest-ssl" points to "Firefox-60.0-SSL" and "firefox-latest-ssl" will erase what's on release * Bad scope "project:releng:bouncer:server:staging" * Bad worker type * release-bouncer-check-firefox: * bad config provided "releases/dev_bouncer_firefox_beta.py" * release-bouncer-sub-firefox: * bad version in path: both version folder and archive file name. * bad bouncer product names, they don't specify "esr" * Bad scope "project:releng:bouncer:server:staging" * Bad worker type There are probably other issues I didn't see. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1434889#c4

Note: The bad version may be because I didn't put "esr" at https://hg.mozilla.org/build/braindump/rev/cf6c4fcd46dd51d76ffc9672d29f8df55c7518ec#l2.12. I currently don't know what release-runner3 gives here. Rail, what do you think?

NI'ing myself to fix this as I worked on the original tasks defs.

From what I remember we usually use app_version to indicate the internal version, and for release branches they never contain letters (b1, esr, etc). Ideally, rr3 shoudn't even let you enter the version/app_version/display_version, and use the in-tree one instead, because it'd be to late at that point to change anything.

Thanks for the context! Per the mozilla-esr52 repo[1], we don't specify "esr" in neither in version_display.txt nor in version.txt. The parameters file in beta[2] shows "b1" in "version", but not in "app_version". Therefore, I'm gonna change the parameters file in braindump with the right data. [1] https://hg.mozilla.org/releases/mozilla-esr52/file/10b7f43b536f/browser/config/version_display.txt and https://hg.mozilla.org/releases/mozilla-esr52/file/10b7f43b536f/browser/config/version.txt [2] For instance: https://queue.taskcluster.net/v1/task/FQ2qRYLCQPGpwT4Nz1fjIg/runs/0/artifacts/public/parameters.yml

Regarding what version should look like, Callek, Rail, and I confirmed: 1. version.txt in tree shouldn't contain anything internal (as in "b1", or "esr") 2. version_display.txt does contain "bX" but not "esr"[1] 3. rr3 takes "version" from ship-it https://dxr.mozilla.org/build-central/source/tools/buildfarm/release/release-runner3.py#194, which contains esr (eg: "60.0esr") 4. "version" in parameters, is given by rr3, like said in 3 Now, with the correct version data: (In reply to Johan Lorenzo [:jlorenzo] from comment #0) > * release-bouncer-aliases-firefox: > * "aliases_entries" are busted. "firefox-esr-latest-ssl" points to > "Firefox-60.0-SSL" and "firefox-latest-ssl" will erase what's on release "firefox-esr-latest-ssl" is mapped to "Firefox-60.0-SSL". However, the alias "firefox-latest-ssl" is still incorrectly named. > * release-bouncer-sub-firefox: > * bad version in path: both version folder and archive file name. This looks better: > "Firefox-60.0esr": { > "options": { > "add_locales": true, > "check_uptake": true, > "ssl_only": true > }, > "paths_per_bouncer_platform": { > "linux": "/firefox/releases/60.0esr/linux-i686/:lang/firefox-60.0esr.tar.bz2", > "linux64": "/firefox/releases/60.0esr/linux-x86_64/:lang/firefox-60.0esr.tar.bz2", > "osx": "/firefox/releases/60.0esr/mac/:lang/Firefox%2060.0esr.dmg", > "win": "/firefox/releases/60.0esr/win32/:lang/Firefox%20Setup%2060.0esr.exe", > "win64": "/firefox/releases/60.0esr/win64/:lang/Firefox%20Setup%2060.0esr.exe" > } > }, [1] This is planned to change in bug 1432737

Comment on attachment 8968190 [details] Bug 1453261 - part1: Fix esr60 kinds in bouncer aliases https://reviewboard.mozilla.org/r/236874/#review242830 Looks good to me, double-checked with aliases in bouncer.

Comment on attachment 8969198 [details] Bug 1453261 - part2: Provide correct config to bouncer checks https://reviewboard.mozilla.org/r/237924/#review243726 ::: testing/mozharness/configs/releases/dev_bouncer_firefox_esr.py:9 (Diff revision 1) > + "bouncer_prefix": "https://bouncer-bouncer-releng.stage.mozaws.net/", > + "products": { > + "installer": { > + "product-name": "Firefox-%(version)s", > + "check_uptake": True, > + "alias": "firefox-esr-latest", Can you also double check that esr52 doesn'tconflict with this alias? ::: testing/mozharness/configs/releases/dev_bouncer_firefox_esr.py:38 (Diff revision 1) > + }, > + }, > + "installer-ssl": { > + "product-name": "Firefox-%(version)s-SSL", > + "check_uptake": True, > + "alias": "firefox-esr-latest-ssl", And here

:mihai, :rail, Do either of you have more context here while johan is away, what is still required to be on central/beta

These are ESR-specific, we can land them anytime to central+beta and let them ride to esr60.

(In reply to Rail Aliiev [:rail] ⌚️ET from comment #12) > These are ESR-specific, we can land them anytime to central+beta and let > them ride to esr60. +1

Worth checking again on a staging release on jamnun that things look good. I can take care of grafting everything to central & beta by EOD.

Pushed by mtabara@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/45bc926dad5c adjust bouncer kinds to handle esr60. r=rail,mtabara CLOSED TREE

Landed both patches to mozilla-inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/45bc926dad5c59e455c5e20c0e4adbd4c8e26772

We failed to graft this patch in time on beta for esr60 mergeduty. We'll wait until the merge is completed and then we'll land this patch to release & esr60. Work for this is tracked in bug 1457090.