[Fennec-Relpro] fennec nightly task: include beta in version number for beetmover when appropriate



Release Engineering
Release Automation
10 months ago
10 months ago


(Reporter: jlorenzo, Assigned: aki)


Firefox Tracking Flags

(Not tracked)


MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Error loading review requests:


(3 attachments)

For the upcoming Fennec Release Promotion, Aki noted candidate builds are sent to https://s3.amazonaws.com/net-mozaws-stage-delivery-archive/pub/mobile/candidates/53.0-candidates/* [1] instead of 53.0b1-candidate.

Beetmover is aware of the version via balrog_props.json[2] which is generated by a buildbot configuration used by mozharness[3]. This buildbot config comes from application.ini[4], which itself gets its value from browser/config/version.txt[5].

We have never encountered this problem on the buildbot infrastructure, because the version is actually defined in the buildbot-config[6].

After discussing with :mshal, it seems we should pass the MOZ_APP_DISPLAY_VERSION, instead of MOZ_APP_VERSION. MOZ_APP_DISPLAY_VERSION was renamed this way in bug 1176533. On IRC, :Sylvestre was okay with us to use this var that way.

[1] For instance https://s3.amazonaws.com/net-mozaws-stage-delivery-archive/pub/mobile/candidates/53.0-candidates/build1/android-api-15/cy/fennec-53.0.cy.android-arm.checksums 
[2] For instance: https://queue.taskcluster.net/v1/task/YmvSQYOzRZiJrHWMzJzbCw/runs/0/artifacts/public/build/balrog_props.json
[3] https://dxr.mozilla.org/mozilla-central/rev/e1135c6fdc9bcd80d38f7285b269e030716dcb72/testing/mozharness/mozharness/mozilla/updates/balrog.py#17 and https://dxr.mozilla.org/mozilla-central/rev/e1135c6fdc9bcd80d38f7285b269e030716dcb72/testing/mozharness/mozharness/mozilla/buildbot.py#64
[4] https://dxr.mozilla.org/mozilla-central/rev/e1135c6fdc9bcd80d38f7285b269e030716dcb72/testing/mozharness/mozharness/mozilla/building/buildbase.py#740
[5] https://dxr.mozilla.org/mozilla-central/rev/e1135c6fdc9bcd80d38f7285b269e030716dcb72/build/application.ini.in#25 and https://dxr.mozilla.org/mozilla-central/rev/e1135c6fdc9bcd80d38f7285b269e030716dcb72/browser/confvars.sh#39 and https://dxr.mozilla.org/mozilla-central/source/old-configure.in#787
[6] https://hg.mozilla.org/build/buildbot-configs/file/7cb9f28ef3ff/mozilla/release-fennec-mozilla-beta.py#l23


10 months ago
Blocks: 1343393
Comment hidden (mozreview-request)
Rev 1 of the patch is being tested at: https://tools.taskcluster.net/task-inspector/#Lb9BO7tsRJCUA73HKP13lQ/

Comment 3

10 months ago
:mtabara - would it make more sense to update balrog_props.json (which will affect the balrog submission as well), or to pass in the version info through the decision task, like build_number ?


* balrog will specify 53.0b1 instead of 53.0
* beetmover will specify 53.0b1 instead of 53.0

task.payload.version ?

* balrog will continue to specify 53.0
* beetmover can specify 53.0b1 instead of 53.0, if it gets the version info from the task payload instead of balrog_props.json
Flags: needinfo?(mtabara)
Good question. I don't have a strong opinion here. However, I never liked the fact that we're so dependent on balrog_props so I'm leaning towards the latter, to use via payload.

(In reply to Aki Sasaki [:aki] from comment #3)
> task.payload.version ?
> * balrog will continue to specify 53.0

Yes and no. We will soon need to alter/add logic in beetmoverscript to generate the correct release-type manifest to fit ahttps://github.com/mozilla-releng/balrogscript/blob/master/balrogscript/script.py#L41 . If we have the task.payload.version at hand, we can use that instead of the version from balrog_props.json and get the correct version in balrog submission for free (per 'toVersion' argument from https://github.com/mozilla-releng/balrogscript/blob/master/balrogscript/script.py#L43 )
Flags: needinfo?(mtabara)


10 months ago
Summary: [Fennec-Relpro] fennec nightly task: pass complete version number to balrog_props → [Fennec-Relpro] fennec nightly task: include beta in version number for beetmover when appropriate

Comment 5

10 months ago
Created attachment 8842558 [details] [review]
add beetmover task.payload.version support
Attachment #8842558 - Flags: review?(mtabara)
Attachment #8842558 - Flags: review?(mtabara) → review+

Comment 6

10 months ago
Created attachment 8842564 [details] [diff] [review]

add task.payload.version to release beetmover tasks.
Attachment #8842564 - Flags: review?(mtabara)
Comment on attachment 8842564 [details] [diff] [review]

Review of attachment 8842564 [details] [diff] [review]:

Wow, this is super smooth approach, nice!
To be honest, I would have added it similarly to the build_number, taking it from the environment passed by from the Ship-it interface.
But we have sanity checks that make sure the Ship-it version is the same with the value from version_display.txt so this is even better! Taking it from the source of truth!
Attachment #8842564 - Flags: review?(mtabara) → review+


10 months ago
Assignee: jlorenzo → aki

Comment 8

10 months ago
bug 1343585 - add task.payload.version to release beetmover tasks. r=mtabara

Comment 9

10 months ago
We still need to land on m-c and uplift to m-a... I think this patch also needs to land in m-i... we can hold off til we verify though.
Testing a new fennec staging beta.

Comment 10

10 months ago
bug 1343585 - add task.payload.version to release beetmover tasks. r=mtabara a=release

Comment 11

10 months ago
Uplifted to aurora, and I believe this is fixed in the staging beta1.
Last Resolved: 10 months ago
Resolution: --- → FIXED

Comment 12

10 months ago
You need to log in before you can comment on or make changes to this bug.