fix(bugsnag): keep the build UUID off create-build - #1377
Merged
Conversation
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=<HEAD>`, and the merged release manifest carries the same SHA in `com.bugsnag.android.BUILD_UUID`.
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
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.
The release deploy has failed since #1374 with
unknown flag --build-uuidfrombugsnagCreateReleaseBuild(run 33406657816). The bundle builds and signs fine; the create-build finalizer kills the job at the end.#1374 set
buildUuidin thebugsnag { variants { release { … } } }block. In bugsnag-gradle-plugin 1.2.0 that one property feeds two CLI calls:upload android-proguard, which accepts--build-uuid— the call fix(bugsnag): give the app and the uploaded mapping the same build UUID #1374 was aiming at.create-build, which does not accept it. The flag is absent from the 3.10.2 binary the plugin embeds and from the options struct in 3.10.5, the current CLI release. Plugin 1.2.0 is also the latest, so no version bump avoids this.autoCreateBuild = truewas already wiring create-build as a finalizer ofbundleRelease, so the unsupported flag went out on every release build. PR CI stayed green because only the deploy workflow runs the Bugsnag tasks.This sets the UUID on the mapping upload task instead of through the DSL, so create-build returns to its working default and the mapping still carries the SHA that the manifest's
com.bugsnag.android.BUILD_UUIDholds. The plugin writes that property only when the DSL supplies a value, so it cannot overwrite the value set here whichever order the two configuration actions run in — worth stating, because the reverse arrangement (clearing the property on create-build) loses silently: the plugin's registration action runs after container-levelconfigureEach.UploadMappingTaskis internal to the plugin, so the task is looked up by name rather than by type. The comment says to drop this once the plugin stops passing the flag to create-build.