Goal here is to start publishing the nightly, beta and production releases of Fenix into our S3 buckets.

This includes, but may not be limited to:

1. add support in taskgraph for beetmover (we already have that since we're using it in AC)
2. tweak https://github.com/mozilla-mobile/fenix/ taskgraph to encompass the beetmover jobs as well as part of the release process
3. grab a new set of credentials from CloudOps for this particular product

I chatted with :bhearsum, this is needed to get buildhub working. This project basically listens to S3 events whenever a new artifact is uploaded to archive.m.o. We could teach buildhub to listen elsewhere but it seems easier to just upload the artifacts.

Status update on this bug:

There are a couple of things to be done for this "Fenic where Fennec lived" goal, mainly:

• ensure we have buildhub.json for Fenix projects as well. There are more details on this project in bug 1622948 which tracks the actual work. tl;dr buildhub.json is generated at build time and automatically shipped by beetmover. Unclear whether we already generate this in Fenix graphs or not, more info in the aforementioned bug
• upload the Fenix artifacts into S3. Historically, until Fennec was EOL'ed, we published the artifacts in https://archive.mozilla.org/pub/mobile/releases/. We need to do similarly for Fenix apks artifacts. Stefan and RyanVM could guide more as to whether we can reuse the same location or have a dedicated one pub/fenix/releases in S3 or such. This work entails adding a beetmover task into the Fenix graphs, similarly to what Android-Components counterpart
• ensure https://www.mozilla.org/ points to Fenix entries only - this is done, no-op on our end, more info in bug 1614762.
• add automated Fenix into Ship-it - this is tracked in bug 1689118 - RyanVM can provide more guidance here but we already have this enabled for desktop apps, at the very least, it'd be a matter of copy-pasting some configs in https://github.com/mozilla-releng/shipit and make sure we have the similar logic for Fenix as well so that we reduce the amount of manual work here for Mobile and Relman teams.

I have a WIP branch going here:
https://github.com/mozilla-mobile/fenix/compare/master...ahal:beetmover

(ignore the contents of beetmover.py and beetmover/kind.yml as they are mostly copied from android-components)

Hoping someone can verify that I'm on the right track.. In android-components it seems like artifacts are being copied to a maven destination? I'm assuming I'll need to replace this with a relative URL on archive.m.o and then somewhere in here we'll translate that to a location on the server and handle auth and all that.

I guess for now I'll target archive.m.o until I hear otherwise.

(In reply to Mihai Tabara PTO_back_15April [:mtabara]⌚️GMT from comment #3)

• upload the Fenix artifacts into S3. Historically, until Fennec was EOL'ed, we published the artifacts in https://archive.mozilla.org/pub/mobile/releases/. We need to do similarly for Fenix apks artifacts. Stefan and RyanVM could guide more as to whether we can reuse the same location or have a dedicated one pub/fenix/releases in S3 or such.

Ryan, as per above do you know where these should be uploaded? Same place as fennec used to be?

(In reply to Andrew Halberstadt [:ahal] from comment #4)

I have a WIP branch going here:
https://github.com/mozilla-mobile/fenix/compare/master...ahal:beetmover

(ignore the contents of beetmover.py and beetmover/kind.yml as they are mostly copied from android-components)

Hoping someone can verify that I'm on the right track.. In android-components it seems like artifacts are being copied to a maven destination? I'm assuming I'll need to replace this with a relative URL on archive.m.o and then somewhere in here we'll translate that to a location on the server and handle auth and all that.

This is correct, we don't want to use maven logic, we want to use non-maven logic. We may be able to reuse some gecko logic here, e.g. https://searchfox.org/mozilla-central/source/taskcluster/taskgraph/transforms/beetmover.py (there are a lot of beetmover tasks and transforms in gecko and we use declarative artifacts (e.g.) there; it may help to look at a gecko release task first.)

I guess for now I'll target archive.m.o until I hear otherwise.

+1

Re: get_nightly_version: good idea making this a shared function. We may want to move it out of the build transform if we use it elsewhere. I'm not 100% sure if we're beetmoving nightlies, or just betas and releases (this probably depends on where we need buildhub.json).

Currently, in gecko, our nightly and release beetmoving follows separate patterns, because nightly and release automation are two different code paths. I'm not sure if we want to follow that here, or jump ahead of gecko and use release-type beetmoving for both nightly and release. (In this case, the nightly-dated dirs could be like the candidate dirs, and the latest dirs could be like the release dirs.)

I have a small preference for using /fenix over /mobile, but I think Stefan should weigh in.

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

I have a small preference for using /fenix over /mobile, but I think Stefan should weigh in.

+1. I'm leaning towards per-product top-level dirs so that credentials are also better divided.

I chose to duplicate the variable rather than use a regex or similar as this
duplication will only be needed temporarily (while consumers are being switched
from PY2->PY3).

This way the patch to remove the PY2 logic can be handled automatically via
pyupgrade.

Clearing stale needinfo.

Depends on D119454

Posted in #releaseduty-mobile (slack)

We need some direction (again) on filename and path for archiving builds to archive.m.o
The logic creating the path is here and here

The last nightly build was uploaded to the staging bucket using the above logic.

Note that the current configured path follows the same as desktop firefox nightly but release and beta follow a different path logic

Another thing to note is that the version info is being fetched from the version.txt file, which right now contains 97.0.0-beta.1.

We need information on how/where to get the right version for nightly, beta and release and if we should different paths for nightly vs beta/release.

Stefan Arentz reply:

i don't think anyone has a strong preference. can you do a proposal? (i personally think it doesn't matter much what the exact path is as long as we can find the builds)

Will create a new PR for the changes above