1193504 - make sure RCs are fully enabled for betas-on-release

Status: RESOLVED FIXED

(Release Engineering :: Release Automation, defect)

Description

[[e-mail] (:bhearsum)]

We hit an issue in 40.0 where Beta update verify and final verify were failing because the Balrog blob did not have "39.0-build6" entries for the beta* fileUrls. This is probably because we use this versionRegex: r"^(\d+\.\d+b\d+|%s)$" % releaseConfig["version"].replace(".", "\\."),


This version regex already support x.ybz, and versions that match the current version numebr. Looks like we need to add support for anything that looks like x.y. I'm tempted jsut to use ^.*$ to simplify things, and support the unlikely case that we've pushed a x.y.z release to beta.

Comment 1

[[e-mail] (:bhearsum)]

Attachment: add all the versions to beta channels

I double checked that the release creator pays attention to this (it does: https://github.com/mozilla/build-tools/blob/master/scripts/updates/balrog-release-pusher.py#L104), so I think this should do the trick?

https://github.com/mozilla/build-tools/blob/master/lib/python/balrog/submitter/cli.py#L191 will take care of constructing the correct URLs, ie: including buildN in the bouncer product name.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Does it mean we end up with x.0.y versions in the beta patcher config, and hence do update verify on strange paths ? I think it might, and end up causing problems when we don't have <x.0.y> blocks in the beta patcher config.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #2)
> Does it mean we end up with x.0.y versions in the beta patcher config, and
> hence do update verify on strange paths ? I think it might, and end up
> causing problems when we don't have <x.0.y> blocks in the beta patcher
> config.

Hmmm, good point. This is basically impossible to get correct when we're guessing :(. We could definitely add support for x.y instead of just currentVersion.y -- that would fix this particular problem, but wouldn't help when we've got a x.y.z that made it to beta...

Comment 4

[[e-mail] (:bhearsum)]

Attachment: allow x.y + x.ybz versions for beta on release

OK, so let's just support all x.y versions for now. This means that any x.y.z versions that make it to Beta would still need fixups in the Balrog blob, but this just fix the majority of the cases.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8649896 [details] [diff] [review]
allow x.y + x.ybz versions for beta on release

>diff --git a/mozilla/config.py b/mozilla/config.py

I'm assuming this was for another bug and ignoring it here.

>diff --git a/mozilla/release-firefox-mozilla-release.py.template b/mozilla/release-firefox-mozilla-release.py.template
>-        "versionRegex": r"^(\d+\.\d+b\d+|%s)$" % releaseConfig["version"].replace(".", "\\."),
>+        "versionRegex": r"^(\d+\.\d+(b\d+)?)$",

WFM!

Comment 6

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #5)
> Comment on attachment 8649896 [details] [diff] [review]
> allow x.y + x.ybz versions for beta on release
> 
> >diff --git a/mozilla/config.py b/mozilla/config.py
> 
> I'm assuming this was for another bug and ignoring it here.

Yeah, whoops =\.

Comment 7

[Release Engineering SlaveAPI Service]

In production: https://hg.mozilla.org/build/buildbot-configs/rev/f75eaef8100f