Skip to content
This repository has been archived by the owner on Jul 9, 2024. It is now read-only.

Don't hardcode expected APK architectures #16

Closed
JohanLorenzo opened this issue Mar 30, 2017 · 3 comments
Closed

Don't hardcode expected APK architectures #16

JohanLorenzo opened this issue Mar 30, 2017 · 3 comments

Comments

@JohanLorenzo
Copy link
Contributor

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 made mozilla-beta (and mozilla-release).

We should not hardcode the expected architecture in pushapkscript. Aki suggested:

  • either to generate the expected list in the decision task
  • or to fetch a file in tree.

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.

@escapewindow
Copy link
Contributor

taskcluster/ci/build/android.yml seems be better choice. We'd just have to filter out the entries with '-nightly/opt' in job_name.

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.

@JohanLorenzo
Copy link
Contributor Author

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.

@JohanLorenzo
Copy link
Contributor Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants