Please provide a manifest file listing all apk files of a version

RESOLVED WONTFIX

Status

P3
normal
RESOLVED WONTFIX
4 years ago
4 months ago

People

(Reporter: sylvestre, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
In order to manage N apk files, a manifest would help a lot to update our various tools.
needinfo'ing Nick here for one thing: does Gradle have an existing format that it uses anywhere to specify variants from a build? I'd rather not reinvent the wheel, particularly because we'll eventually end up using variants…
Flags: needinfo?(nalexander)
(In reply to Richard Newman [:rnewman] from comment #1)
> needinfo'ing Nick here for one thing: does Gradle have an existing format
> that it uses anywhere to specify variants from a build? I'd rather not
> reinvent the wheel, particularly because we'll eventually end up using
> variants…

I'm not 100% sure what this manifest would contain, but I don't know of a clear artifact expressing this that Gradle provides out of the box.  We could write such a manifest as part of the Gradle task graph, certainly, but it'd just be a collection of things we stick into the Gradle configuration at build time: SDK version, debuggable, Proguard, ABI, etc, etc.
Flags: needinfo?(nalexander)
(Reporter)

Updated

4 years ago
Summary: Please provide a manifest file listing all apk file of a version → Please provide a manifest file listing all apk files of a version
Component: Other → Release Automation
QA Contact: pmoore → bhearsum
Myself and nick are going to meet next week about how to improve the process of package naming and the subsequent down-stream digestion from releng infra.

Up until now, releng has largely been uninvolved with how we determine apk names and instead just parsed the bits that come from in-tree: iiuc, it's these files that do that work: http://mxr.mozilla.org/mozilla-central/search?string=PKG_BASENAM

It would be great to collaborate on a process that allowed better parsing/extending (e.g. a manifest of sorts)
we are in the middle of switching from ftp to s3 for uploading packages. In line with this bug, it seems an opportune time to re-evaluate how we determine package names and upload them.

for reference: https://bugzil.la/1117960
See Also: → bug 1117960
after discussing this with nick later last week, I think the 'wants' in this bug are for two different things. Nick is looking for a manifest that that can easily define what we name our packages and upload. Something that is mostly static bar things like branch name and gecko version. This would live in tree and replace some of the logic in locations like these[1] and then read by our jobs in mozharness instead of doing things like this[2]

I think the purpose of this bug is to help a step during releases. iow - post release build steps.

There is a large push this quarter to bring mozharness in tree[3]. At the same time we are also porting our android builds to use mozharness and task cluster[4]. Between these two things, this will change the landscape of how package names are decided and what gets uploaded. I don't think it is worth investigating until both of those are completed.

I am going to dep this against the mentioned bugs rather than close this for now. Happy to discuss more if you feel I am interpreting things incorrectly.

[1] http://mxr.mozilla.org/mozilla-central/search?string=PKG_BASENAM
[2] http://mxr.mozilla.org/build/source/mozharness/mozharness/mozilla/building/buildbase.py#82
[3] https://bugzil.la/1131856
[4] https://bugzil.la/1118394
Depends on: 1131856, 1118394
No longer blocks: 1120762
Depends on: 1120762
Priority: -- → P3

Comment 6

9 months ago
We've made a lot of changes to how we upload and manage apks; is this still needed?
Flags: needinfo?(sledru)
(Reporter)

Comment 7

9 months ago
In a perfect world, probably but we have been living without that for so long...
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Flags: needinfo?(sledru)
Resolution: --- → WONTFIX
See Also: → bug 1466714
You need to log in before you can comment on or make changes to this bug.