[SDK-7461] fix(setup-env): do not export a build/project name the workflow never set

[rounak610]

SDK-7461 fix(setup-env): do not export a build/project name the workflow never set

Fixes the customer-facing bug in SDK-7461 (easyJet). Root-caused to setup-env and verified by executing the built action, not by reading source. The change is confined to setup-env.

Issue — env-injected defaults silently outrank browserstack.json (SDK-7461)

ActionInput.setEnvVariables() in setup-env/src/actionInput/index.js exported BROWSERSTACK_PROJECT_NAME and BROWSERSTACK_BUILD_NAME unconditionally, even when the workflow supplied neither project-name nor build-name:

core.exportVariable(ENV_VARS.BROWSERSTACK_PROJECT_NAME, this.projectName);
core.exportVariable(ENV_VARS.BROWSERSTACK_BUILD_NAME, this.buildName);

By this point _validateInput() has already replaced the two blank inputs with generated defaults — validateProjectName() → github.context.repo.repo (the repo name), validateBuildName() → _getBuildInfo() → <event> [Workflow: <run number>].

Every BrowserStack SDK resolves names as CLI args > env vars > config file. So exporting a generated default does not fill a gap — it outranks whatever the user configured in browserstack.json / browserstack.yml and silently replaces it, with no way to opt out.

Customer impact. easyJet's browserstack.json declares E2E_Automation for both names. Their failing build instead showed:

project : core-automation-framework          (= their repo name)
build   : workflow_dispatch [Workflow: 7]     (= <event> [Workflow: <run#>])

Neither string exists anywhere in their repository. This was our own remedy in SDK-7124, which told them to add setup-env with only username, access-key and github-token — so the defaults fired and discarded their config. It also explains the reported "build missing from the old dashboard": TRA reads the env var, Automate reads the config, so the two dashboards filed the run under different names.

Reproduced by execution. Running the built action as a runner does, with the exact SDK-7124 inputs, produced core-automation-framework and workflow_dispatch [Workflow: 7] byte-for-byte.

Fix

Export each name variable only when its input was actually supplied; when it was left blank, log an explicit core.info line and leave the variable unset so the user's own configuration wins.

• Captured buildNameProvided / projectNameProvided in the constructor, before _validateInput() overwrites the blanks with generated defaults — that is the only point where "did the workflow ask for a name?" is still observable.
• Guarded both core.exportVariable calls on those flags.
• The generated values are not lost: InputValidator already understands the BUILD_INFO and REPO_NAME tokens (documented in the README). Those tokens are the intended, explicit opt-in — applying them implicitly is what made them redundant and what broke user config. README updated to document this.
• Rebuilt setup-env/dist/index.js with ncc (the committed bundle is what the action runs). Verified reproducible: a fresh npm run build produces zero diff against the committed dist.

⚠️ Blast radius — please read before merging

This changes behaviour for every workflow that uses setup-env without build-name/project-name and relies on the generated names. Their builds now fall back to whatever the SDK/config resolves. Any such user restores the previous behaviour with one line:

with:
  build-name: BUILD_INFO
  project-name: REPO_NAME

Our docs recommend pinning @master, so this reaches every user the moment it merges — there is no gradual rollout. This warrants a maintainer call on timing and a release note. Flagging explicitly rather than assuming.

Verified behaviour matrix

Does the TRA dashboard name agree with the Automate dashboard name?

setup-env inputs / workflow	master	with this fix
no names, no --build-name	SPLIT	MATCH
no names, with --build-name	SPLIT	MATCH
explicit names, no --build-name	MATCH	MATCH
explicit names + differing --build-name	SPLIT	SPLIT¹

¹ The last row is a separate CLI name-precedence gap (browserstack-cypress-cli), tracked independently — not in scope for this setup-env change.

Testing

Suite	master	this branch
setup-env mocha	37 passing / 0 failing	43 passing / 0 failing
setup-env eslint	clean	clean
dist reproducibility	—	npm run build → 0 diff

Node 20 (v20.11.1), npm test (lint + mocha). Six new test cases assert the guarded behaviour:

• Records that build-name and project-name were supplied
• Records that build-name and project-name were NOT supplied when absent
• Treats a whitespace-only name input as not supplied
• Does not export BROWSERSTACK_PROJECT_NAME when no project-name input was given
• Does not export BROWSERSTACK_BUILD_NAME when no build-name input was given
• Exports neither name when neither input was given, leaving the user config to win

---

Ticket: SDK-7461 · Predecessor context: SDK-7124

🤖 Generated with Claude Code

[shayan-bstack]

trim too many code comments

[rounak610]

Done in d2e8a43 — source comment reduced from 8 lines to 2 and dist rebuilt from it. 43 tests still passing, eslint clean.

[shayan-bstack]

Trim it here as well

[rounak610]

Done in d2e8a43 — this is the bundled dist; regenerated with npm run build (ncc) after trimming the source comment, so it now carries the shortened version.

[shayan-bstack]

Trim comments

[rounak610]

Done — trimmed to a single line in d2e8a43, keeping just the non-obvious why (capture must happen before _validateInput() replaces blanks with generated defaults).