Choose a package type/extension for `mobile/android` after Fennec is removed
Categories
(Firefox Build System :: Task Configuration, task)
Tracking
(Not tracked)
People
(Reporter: nalexander, Unassigned)
References
Details
Many places in the build system and the releng ecosystem expect "a build" to produce "a package". When we remove Fennec, the Fennec APK will no longer be "the package". The natural candidate package is the GeckoView AAR, but that's not really enough to be useful. We probably wanted target.maven.zip
but that was removed by Bug 1563711. So it's not clear what the resulting "package" should be. Or if we even require a "package" in the traditional sense.
Reporter | ||
Comment 1•5 years ago
|
||
I will note that for Bug 1580356 I intend to disable publishing package metrics (i.e., disable_package_metrics: true
) for Android builds and to work around the lack of download information in informulate.py
.
jlund: perhaps you can comment on what you think should happen, and/or redirect to others who might have opinions?
Reporter | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
Do we even need to build from mobile/android after Fennec is removed? I guess this build will be what GV is based off of? We just won't have Fennec?
If releng doesn't require a package to be defined (e.g. we strip all mentions of it from our declared artifacts), we wouldn't have any objection to not creating a package.
302 -> mtabara / jlorenzo. We started talking out EOL fennec and what that will mean for us. What do you think for this ticket?
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Jordan Lund (:jlund) from comment #2)
Do we even need to build from mobile/android after Fennec is removed? I guess this build will be what GV is based off of? We just won't have Fennec?
Correct: --enable-application=mobile/android
will build GeckoView. (Right now it builds Fennec and GeckoView.)
Comment 4•5 years ago
•
|
||
First of all, please bear with me - just to make sure we're all on the same page:
-
by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?
-
IIUC, we now have
ship_geckoview
in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. Bythe Fennec APK will no longer be "the package
you specifically talk about no longer building thispublic/build/target.apk
(e.g. in this task). Correct?
If so, I don't think we actually need any replacement, nor any form of packaging. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that target.apk
will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.
LATER EDIT: seems like we actually do sign the apk
with the autograph_apk_fennec_sha1
format but we never actually ship those in the maven.m.o . The beetmover declarative artifacts (such as this) stands proof as there's no trace of target.apk
around there. I strongly suspect this was carried over while we did some migration to Autograph earlier this year.
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #4)
First of all, please bear with me - just to make sure we're all on the same page:
- by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?
Correct. I wouldn't expect to uplift anything at all, so this would be "deleting tons of stuff from m-c" and then having it ride the trains.
- IIUC, we now have
ship_geckoview
in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. Bythe Fennec APK will no longer be "the package
you specifically talk about no longer building thispublic/build/target.apk
(e.g. in this task). Correct?
Correct, not building target.apk
. My try builds are green now but I'll follow up with N
and Ns
tasks to see what happens. Presumably we need to remove the Ns
tasks (and potentially other tasks) since there'll be no Fennec APK to sign shortly.
If so, I don't think we actually need any replacement, nor any form of packaging. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that
target.apk
will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.
OK: it sounds like there's no releng need for a package, since we're doing much, much more flexible things for the Maven artifacts already. That's great!
LATER EDIT: seems like we actually do sign the
apk
with theautograph_apk_fennec_sha1
format but we never actually ship those in the maven.m.o .
That's true, but I think we have some capability to ship a Fennec APK from m-c to Google Play. That's disabled right now ('cuz esr68 is servicing those APKs) but the capability should be removed from m-c as well. Perhaps that is the cleanup you are referring to?
The beetmover declarative artifacts (such as this) stands proof as there's no trace of
target.apk
around there. I strongly suspect this was carried over while we did some migration to Autograph earlier this year.
Roger that.
Comment 6•5 years ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #5)
(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #4)
First of all, please bear with me - just to make sure we're all on the same page:
- by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?
Correct. I wouldn't expect to uplift anything at all, so this would be "deleting tons of stuff from m-c" and then having it ride the trains.
Sounds good. Cleanup is good :D
- IIUC, we now have
ship_geckoview
in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. Bythe Fennec APK will no longer be "the package
you specifically talk about no longer building thispublic/build/target.apk
(e.g. in this task). Correct?Correct, not building
target.apk
. My try builds are green now but I'll follow up withN
andNs
tasks to see what happens. Presumably we need to remove theNs
tasks (and potentially other tasks) since there'll be no Fennec APK to sign shortly.
Sounds good! again, much welcomed cleanup!
If so, I don't think we actually need any replacement, nor any form of packaging. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that
target.apk
will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.OK: it sounds like there's no releng need for a package, since we're doing much, much more flexible things for the Maven artifacts already. That's great!
+1
LATER EDIT: seems like we actually do sign the
apk
with theautograph_apk_fennec_sha1
format but we never actually ship those in the maven.m.o .That's true, but I think we have some capability to ship a Fennec APK from m-c to Google Play. That's disabled right now ('cuz esr68 is servicing those APKs) but the capability should be removed from m-c as well. Perhaps that is the cleanup you are referring to?
Yes, and I'll track that cleanup on our side in a separate bug to ensure we remove any reference in our ecosystem too.
Comment 7•5 years ago
|
||
bug 1584144 is now tracking RelEng follow-up cleanup in our ecosystem, once :nalexander's patches land on central.
Comment 8•5 years ago
|
||
Clearing NI because Mihai answered the questions. Thank you very much! 😃
Comment 9•5 years ago
|
||
I think we can close this. Nick already pushed the Fennec removal patches while Johan is tracking the cleanup in RelEng world under bug 1586748.
Feel free to re-open should I'm wrong.
Description
•