Open Bug 1956874 Opened 21 days ago Updated 2 days ago

Don't use fat AARs as inputs to Fenix lints

Categories

(Firefox for Android :: Tooling, enhancement)

All
Android
enhancement

Tracking

()

People

(Reporter: nalexander, Unassigned)

References

(Blocks 1 open bug)

Details

I noticed that all of the Fenix-specific lints depend on fat AARs: see https://searchfox.org/mozilla-central/rev/ac605820636c3b964542a2c0589af04a02235d00/taskcluster/kinds/source-test/android-lint.yml#18-19.

The fat AAR jobs build for multiple architectures and then do another build for good luck. It's probably 1+ hour end-to-end.

Here, it's almost certainly unnecessary. None of these lints should depend on multiple architectures, and in fact, none should depend on native code at all. So we should be able to run these lints against artifact builds, or even better -- as all of the other lints that don't even consume a compiled GeckoView.

This might be related Bug 1891723, which might change how GeckoView is consumed in the underlying tasks.

Aye. There are least 2 things happening here:

  1. The build failure you link to is caused by GV not being published exactly the same with a Ba single-architecture build compared to a fat AAR B job. That could be fixed, but the real issue is that these a-c jobs are built around Maven, not around Gradle projects.
  2. After we address the Maven repository in the middle of these build jobs, we have 3 subtly different configurations for building GeckoView:
  • GeckoView with no native libraries (for lints and unit tests that don't actually run Gecko);
  • GeckoView with native libraries coming from somewhere else (e.g., artifact builds);
  • GeckoView with native libraries built as part of the build job (e.g., full builds).
    Right now it's hard to know when to use each build type and harder still to arrange each type when needed.
You need to log in before you can comment on or make changes to this bug.