From f91fc20948fb93f1fcb7f79952cbbfe70c33f9c0 Mon Sep 17 00:00:00 2001 From: Brandon McAnsh Date: Mon, 31 Aug 2026 11:45:46 -0400 Subject: [PATCH] fix(bugsnag): keep the build UUID off create-build MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The release deploy has failed since #1374 with `unknown flag --build-uuid` from `bugsnagCreateReleaseBuild`. bugsnag-gradle-plugin 1.2.0 hands the variant's `buildUuid` to two CLI calls: `upload android-proguard`, which accepts `--build-uuid`, and `create-build`, which does not — the flag is absent from the 3.10.2 the plugin embeds and from 3.10.5, the current release. PR CI never caught it because only the deploy workflow runs the Bugsnag tasks. Set the UUID on the mapping upload task instead of through the `bugsnag` block, so create-build goes back to its working default. The plugin only writes that property when the DSL supplies a value, so it cannot overwrite this one regardless of which configuration action runs first. Verified against a stand-in CLI that records its arguments: create-build now passes no `--build-uuid` and keeps the rest of its flags, the mapping upload passes `--build-uuid=`, and the merged release manifest carries the same SHA in `com.bugsnag.android.BUILD_UUID`. --- apps/flipcash/app/build.gradle.kts | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/apps/flipcash/app/build.gradle.kts b/apps/flipcash/app/build.gradle.kts index 502200040..3bea39703 100644 --- a/apps/flipcash/app/build.gradle.kts +++ b/apps/flipcash/app/build.gradle.kts @@ -1,6 +1,7 @@ import com.android.build.api.variant.BuildConfigField import com.bugsnag.gradle.dsl.debug import com.bugsnag.gradle.dsl.release +import org.gradle.api.provider.Property import org.jetbrains.kotlin.gradle.dsl.JvmTarget plugins { @@ -30,7 +31,7 @@ fun gitVersionCode(): Int { // to applicationId + versionName + versionCode. Neither side was supplying one: the Gradle // plugin emits the UUID as a string resource that bugsnag-android never reads (it looks for // manifest meta-data only) and that resource shrinking strips anyway, and the mapping upload -// omits `build-uuid` unless the `bugsnag` block below sets it. The commit SHA gives both +// omits `build-uuid` unless it is set on the upload task below. The commit SHA gives both // sides the same value — the app build and the upload task run against the same HEAD in the // release workflow — and going through the manifest keeps it out of the shrinker's reach. val bugsnagBuildId: String = providers.exec { @@ -139,7 +140,6 @@ bugsnag { variants { release { autoCreateBuild = true - buildUuid = bugsnagBuildId } debug { enabled = false @@ -147,6 +147,21 @@ bugsnag { } } +// The build UUID goes on the mapping upload alone, not through `buildUuid` in the block +// above. That property feeds two bugsnag-cli calls: `upload android-proguard`, which takes +// `--build-uuid`, and `create-build`, which has never accepted it — not in the 3.10.2 that +// bugsnag-gradle-plugin 1.2.0 embeds, nor in 3.10.5, the current release. Setting it there +// fails the release build with `unknown flag --build-uuid`, so set it on the one task that +// wants it and leave create-build on its working default. The plugin only writes this +// property when the DSL supplies a value, so it will not overwrite what is set here whichever +// order the two configuration actions run in. UploadMappingTask is internal to the plugin, +// hence the lookup by task name. +tasks.matching { it.name == "bugsnagUploadReleaseProguardMapping" }.configureEach { + @Suppress("UNCHECKED_CAST") + val buildUuid = javaClass.getMethod("getBuildUuid").invoke(this) as Property + buildUuid.set(bugsnagBuildId) +} + composeCompiler { // Isolated Projects-safe root access (see AndroidLibraryComposeConventionPlugin). stabilityConfigurationFiles.add(