fix(SDK-4165): keep buildIdentifier when BROWSERSTACK_BUILD_NAME is set (v8 backport of #192)

[harshit-browserstack]

What is this about?

Backport of #192 to the v8 line. SDK-4165 is titled [Framework- WDIO v8 v9], and the defect is present on v8 at packages/browserstack-service/src/launcher.ts:1069 — the same line #192 fixed on main.

Launcher._handleBuildIdentifier skipped buildIdentifier resolution whenever BROWSERSTACK_BUILD_NAME was set, even though a buildName was available. The skip was also partial: it removed buildIdentifier from the capabilities but left this._buildIdentifier holding the unresolved #${BUILD_NUMBER} template, which is forwarded to TestHub as build_identifier. Successive runs sharing a build name therefore collapsed into one build instead of name #1, name #2.

The guard now keys only on a missing buildName, and the skip path clears _buildIdentifier. This is a clean cherry-pick of fddde2a from #192 — no conflicts, identical change.

Related Jira task/s

SDK-4165 — [Framework- WDIO v8 v9] Builds are getting merged for GRR user for AA session in o11y dashboard
v9 counterpart: #192

Release (mandatory for every PR — required for the ready-for-review label)

Version bump: (required — tick exactly one)

• minor (backwards-compatible feature)
• patch (bug fix or other small change)

Release notes type: (optional)

• New Feature
• Bug Fix
• Other Improvement

Release notes (customer-facing): (optional but encouraged)

• Fixed buildIdentifier being ignored when the BROWSERSTACK_BUILD_NAME environment variable is set. Successive runs that share a build name are now reported as separate builds (my-build #1, my-build #2) instead of merging into one.

Release notes (internal): (required — engineer-facing; what actually changed / why)

• v8 backport of fix(SDK-4165): keep buildIdentifier when BROWSERSTACK_BUILD_NAME is set #192: _handleBuildIdentifier no longer skips resolution because BROWSERSTACK_BUILD_NAME is set; the guard keys only on a missing buildName.
• The skip path clears this._buildIdentifier, so the unresolved #${BUILD_NUMBER} / ${DATE_TIME} template is no longer sent to TestHub as build_identifier.

Checklist

• Ready to review
• Has it been tested locally?

How this was tested

• Unit tests on v8: tests/launcher.test.ts — 115/115 pass (run from the package after npm run generate, as test-isolated.mjs does).
• Negative control: with the old launcher.ts restored and the new tests kept, the two new cases fail — "should still resolve buildIdentifier when buildName is in caps and BROWSERSTACK_BUILD_NAME is set" and "should not retain an unresolved buildIdentifier template when the identifier is skipped" — so they genuinely exercise the fix. (A third, pre-existing case also fails in that state only because the first failing test exits before deleting the BROWSERSTACK_BUILD_NAME env var it set; with the fix, all 115 pass.)
• Type check: tsc -p tsconfig.prod.json --noEmit clean.
• End-to-end: the same-build-name merge reproduction and fixed-state runs are in fix(SDK-4165): keep buildIdentifier when BROWSERSTACK_BUILD_NAME is set #192 (v8 sample against the fix, plus a WDIO v9 re-verification). A WDIO v8 regression run against this branch is pending.

PR Validations

Run Tests: Comment RUN_TESTS to trigger sanity tests.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited), Workspace UI (inherited)

Review profile: ASSERTIVE

Plan: Enterprise

Run ID: 00fc9d51-3289-4aa5-bf8a-c8f61fd18476

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}