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…

(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.

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

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

We've made a lot of changes to how we upload and manage apks; is this still needed?

In a perfect world, probably but we have been living without that for so long...