ci: scope publish build to library modules + add job timeout#16
Merged
Conversation
Fiona2016
force-pushed
the
ci/scope-publish-build
branch
from
c0384ce to
852a320
Compare
The publish job ran `./gradlew clean assembleRelease`, which assembles the entire project — including the sample apps (sample/*, each with Us1–Us5 flavors), benchmark and tooling modules — none of which are published. That pushed the build past 2 hours. - Replace the project-wide `assembleRelease` with `clean bundleReleaseAar testReleaseUnitTest`. `bundleReleaseAar` is an Android-library-only task, so it packages every publishable library's AAR (a real fail-fast build gate) while skipping the sample application modules, which produce APK/AAB and have no AAR task. `testReleaseUnitTest` compiles and tests the library release sources. The publish task below then uploads exactly the publishable modules. - Add `timeout-minutes: 90` so a stuck build is killed instead of running up to GitHub's 6h default. The limit is loose on purpose: a known-good release run has taken ~52 min and the Maven Central upload is network-bound, so a tighter cap risks killing legitimately-slow publishes; an over-run only wastes extra minutes, which are free on this public repo. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fiona2016
force-pushed
the
ci/scope-publish-build
branch
from
852a320 to
f2039e0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The publish job's
Build projectstep ran./gradlew clean assembleRelease, which assembles the entire project — including the sample apps (sample/*, each withUs1–Us5product flavors), plusbenchmarkandtoolsmodules. None of those are published, but they dominate the build: a recent snapshot run sat in this step for 2h+ (3800+ Gradle tasks, mostly:sample:wear:*Us{1..5}Release). The job also had notimeout-minutes, so a stuck build can run up to GitHub's 6h default.Change
assembleRelease+ separatetestReleaseUnitTeststeps with a single scoped step:./gradlew clean bundleReleaseAar testReleaseUnitTest.bundleReleaseAaris an Android-library-only task — it packages each publishable module's.aar. The sample application modules produce APK/AAB and have no AAR task, so they're skipped automatically. This keeps a real, fail-fast artifact-packaging gate before publishing, without building the sample apps.testReleaseUnitTestcompiles and tests the library release sources.timeout-minutes: 90so a stuck build is killed instead of running to the 6h default. Loose on purpose: a known-good release run has taken ~52 min and the Maven Central upload is network-bound, so a tighter cap risks killing legitimately-slow publishes; an over-run only wastes minutes, which are free on this public repo.Why this is the right scope
bundleReleaseAaris robust to upstream syncs: any new library module is included automatically, any new application module is excluded automatically — no hand-maintained module list. (Verified via--dry-run: the heavysample:kotlin/wear/tv/automotiveapp modules are not in the task graph; only library modules are.)publishAllPublicationsToMavenCentralRepositorystep still assembles + signs + uploads exactly the publishable modules.