Uh oh!
There was an error while loading. Please reload this page.
feat(android): --gradleFlavor to build a product flavor - #6133
Conversation
An app that declares product flavors in its gradle configuration could not tell the CLI which one to build - it always ran `assembleDebug` / `assembleRelease`, which fails outright once flavors exist. `--gradleFlavor foo` inserts the flavor into the task name, so the CLI runs `assembleFooDebug`, `assembleFooRelease`, `bundleFooDebug` or `bundleFooRelease`. The flavor is capitalized to match the gradle task naming. The build output does not need any special handling: gradle writes a flavored build to `build/outputs/apk/<flavor>/<buildType>`, which the existing recursive package lookup and its `-.*-(Debug|Release)` regex already cover. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Warning Review limit reached
Next review available in:31 minutes Limit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Uh oh!
There was an error while loading. Please reload this page.
What
An app that declares product flavors in its gradle configuration has no way to tell the CLI which one to build. The task name is built as:
so the CLI always asks for
assembleDebug/assembleRelease— which gradle rejects once flavors exist, because there is no flavourless variant to assemble.--gradleFlavor fooinserts the flavor into the task name:The flavor is capitalized to match gradle's task naming, and a flavor that is already capitalized is left alone.
Build output
No special handling needed. A flavored build lands in
build/outputs/apk/<flavor>/<buildType>with a name likeapp-foo-debug.apk.getAllAppPackagesalready falls back to a recursive walk of the output directory, and the androidgetValidBuildOutputDataregex iswhich matches the flavored name as is.
Tests
npm test— 1860 passing. Added cases intest/services/android/gradle-build-args-service.tsfor the debug, release, app bundle and already-capitalized forms.Notes
From https://github.com/Akylas/nativescript-cli. Independent of #6129, #6130, #6131 and #6132, though it adds an option next to
gradlePathinlib/options.tslike some of those do — expect a small textual conflict depending on merge order.