-
Notifications
You must be signed in to change notification settings - Fork 7
Don't hardcode expected APK architectures #16
Comments
Usually yes, though I could see us building a nightly that we don't ship, or having a disabled nightly. You could look at the task graph artifact from the builds' decision task. We could also hardcode architecture lists in the branch config in pushapkscript (aurora has this list; beta has this other list), with the caveat that we may have to adjust those on merge day. I do see why you're concerned about getting stuff through the task definition, but if the decision task builds that info using the same logic, then someone would have to alter the decision task logic for this to be a problem. One way would be to have both: the decision task sends the expected list through the task definition, and you have per-channel expected lists on the pushapkscript side. This means we'll have to change two places, but it means we'll see the error post- merge day. Whichever solution we choose, I'm not sure we'll change this list often. We just want to catch it when this changes. |
Bug 1366404 re-ignited the discussion. I'm not sure whether we can to publish a new kind of Nightly yet (question asked in bug 1368484). As a consequence, I believe the best solution, for now, is to hardcode architecture lists in the branch config, just like @escapewindow suggested. Adding a new type of architecture also needs a patch in mozapkpublisher. I'll take care of that. |
One more thought. The Fennec team didn't want to publish Nightlies on Google Play. That's one more reason to keep pushapkscript strict, and not look at the decision task. I think we can keep the "per branch" config like implemented in #21 |
Like @escapewindow said in #15 (comment), there will probably be a time where the expected architectures differ depending on the channel. For instance:
mozilla-aurora
may have an extra new architecture which hasn't mademozilla-beta
(andmozilla-release
).We should not hardcode the expected architecture in
pushapkscript
. Aki suggested:I'm not a big fan of the first solution. Changing the task definition (in the decision task) seems risky. Checking the expected architecture is a footgun protection against bad task definition.
Regarding the second solution, it seems the mozconfig folder contains all the architecture currently built. Looking at this folder means we have to download an archive of
mobile/android/config/
which seems a bit overkill.taskcluster/ci/build/android.yml seems be better choice. We'd just have to filter out the entries with
'-nightly/opt' in job_name
.The text was updated successfully, but these errors were encountered: