Builds — Overview (7.x Beta)

7.x Beta

The build-data pipeline is new and substantially expanded in 7.x. Build timings, dependency graphs, vulnerability scans, and size analysis all flow through the same upload — but each surface is independently gated by a DSL block and rendered on a separate dashboard tab.

When the Bugsee Gradle plugin is applied, every release variant emits a single build record to Bugsee at assemble-finalisation time. That one record carries up to four independent payloads:

Surface	What it carries	Where it shows up	Documentation
Timings	Per-task wall-clock spans, bucketed into managed-code / native / resources / packaging / other; "vs previous build" regression deltas	Build detail → Timings tab	Timings
Dependencies	Resolved runtime classpath as a DFS-ordered list — every library, project, and file entry with direct-vs-transitive provenance	Build detail → Dependencies tab	Dependencies
Vulnerabilities	Server-side OSV.dev scan over the dependencies list, with CVSS-scored CVE findings cross-referenced against GitHub Security Advisory	Build detail → Dependencies tab (vuln strip above the table)	Vulnerabilities
Size analysis	AAB / APK + R8 mapping uploaded for server-side breakdown; treemap, file-level diffs, insights	Build detail → Size tab	Build size analysis

The upload pipeline

From your CI's perspective, all four payloads are one upload per release variant. The plugin's BundleUploadTask runs at the end of assemble / bundle, builds the optional artefacts on-demand (a deterministic zip wrapper for the AAB/APK, a gzipped JSON for the dependency tree, a gzipped JSON for the timing details), and issues a single:

POST /v2/apps/{app_token}/builds

with flags request_artifact_upload, request_dependencies_upload, request_timings_upload reflecting which surfaces you have enabled. The Bugsee backend creates the build record, returns up to three presigned S3 PUT URLs alongside build_id, and the plugin streams the blobs in parallel with independent best-effort try/catch — one failed PUT never breaks the others.

Worker jobs then process each blob asynchronously. Each surface flips its own _status field on the build record, and the dashboard's per-tab visibility gates on those fields, so customers see data appear progressively over tens of seconds rather than waiting for the slowest dimension.

The lifecycle differs slightly per surface:

• timings_status / dependencies_status / size_analysis_status transition uploading → processing → ready / failed.
• vuln_scan_status transitions never → queued → scanning → ready / failed (no upload step — the scan reads the dependencies blob the worker already received).

Vulnerability scanning typically takes the longest because it depends on OSV.dev round-trips.

What you opt into

Everything build-related sits under the single top-level bugsee { buildInfo { … } } block. The master gate is buildInfo.enabled — set it to false and no build record is uploaded at all. Defaults are tuned so that on the release variant, you opt into each sub-feature by leaving its enabled flag at its default and reaping the data; opt out per feature when you don't want it:

build.gradle.kts

bugsee {
    buildInfo {
        // Master gate — flip to false to disable every build upload below.
        // Default: true.
        // enabled.set(true)

        // Include non-release variants too. Default: false (release only).
        // allBuildTypes.set(false)

        // Task-by-task wall-clock spans. Default: true.
        timings {
            enabled.set(true)
        }

        // Resolved runtime classpath. Default: true.
        // OSV vulnerability scanning is automatic when dependencies are present.
        dependencies {
            enabled.set(true)
        }

        // AAB / APK + mapping → treemap and size diffs. Default: false (opt-in).
        sizeAnalysis {
            enabled.set(true)
        }
    }
}

build.gradle

bugsee {
    buildInfo {
        // Master gate — flip to false to disable every build upload below.
        // Default: true.
        // enabled.set true

        // Include non-release variants too. Default: false (release only).
        // allBuildTypes.set false

        timings {
            enabled.set true              // task-by-task wall-clock spans. Default: true.
        }
        dependencies {
            enabled.set true              // resolved runtime classpath. Default: true.
        }
        sizeAnalysis {
            enabled.set true              // AAB / APK + mapping. Default: false (opt-in).
        }
    }
}

See the Gradle plugin reference for the full DSL surface.

When data becomes visible

The dashboard's build detail page renders each tab the moment its _status flips to ready. Typical timing on a healthy build:

• Dependencies + Timings: a few seconds after upload — the worker jobs are pure JSON normalisation + diff.
• Size analysis: tens of seconds to a few minutes, depending on artefact size — the worker decomposes the AAB/APK and builds the treemap.
• Vulnerabilities: typically under a minute, sometimes longer when OSV.dev is rate-limited or returns many findings. A manual "Re-scan" affordance is available with a 3-hour cooldown.

What's next

• Timings — per-task wall-clock spans, categories, regression deltas, the Gantt waterfall view.
• Dependencies — declared and transitive dependencies, DSL knobs for scope and selection-reason capture.
• Vulnerabilities — OSV scan, severity buckets, manual re-scan, advisory drill-down.
• Build size analysis — the existing dedicated page for AAB / APK breakdown, baseline comparison, in-build size check.