Right now, regular opt fat AAR builds run in under 10 minutes because they simply take the already-existing architecture-specific build artifacts and merge them into a single build. However, shippable fat AAR builds require a new build to be created by the build since multi-l10n support is needed and the individual shippable artifacts don't support that. As a result, these jobs typically take 50+ minutes to run and exist as a bottleneck in the overall Android build pipeline as they block downstream AC/Fenix/Focus builds. I've got a patch in bug 1918644 which cuts down on some of that runtime by switching to beefier instance types, but it seems like we'd ideally be able to get that multi-l10n work out of the fat AAR job entirely so that the shippable job can have a comparable runtime to the non-shippable job. I understand that we probably don't want to default the arm32 shippable build to multi-l10n by default so things would Just Work, but I'm wondering if one option might be to add a new multi-l10n shippable build type that only the fat AAR depends on so it can be built in parallel with the other GeckoView builds. Thoughts?
Bug 1918653 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Right now, regular opt fat AAR builds run in under 10 minutes because they simply take the already-existing architecture-specific build artifacts and merge them into a single build. However, shippable fat AAR builds require a new build to be created by the build since multi-l10n support is needed and the individual shippable artifacts don't support that. As a result, these jobs typically take 50+ minutes to run and end up being a bottleneck in the overall Android build pipeline as they block downstream AC/Fenix/Focus builds. I've got a patch in bug 1918644 which cuts down on some of that runtime by switching to beefier instance types, but it seems like we'd ideally be able to get that multi-l10n work out of the fat AAR job entirely so that the shippable job can have a comparable runtime to the non-shippable job. I understand that we probably don't want to default the arm32 shippable build to multi-l10n by default so things would Just Work, but I'm wondering if one option might be to add a new multi-l10n shippable build type that only the fat AAR depends on so it can be built in parallel with the other GeckoView builds. Thoughts?