fix: visual tests workflow build var

[pravusjif]

Change env var used by the visual tests workflow so that it fetches the correct PR builds.

[pravusjif]

/visual-tests

[github-actions]

New build in progress, come back later!

[github-actions]

Visual regression tests (macos)

❌ Visual tests failed.

Platform	macos
Mode	test
Commit	3b1b23d
Branch	test/trigger-visual-tests-2
Tests ref	main
Filter	Category=Visual
Allure report	not generated
Workflow run	#26293427404

_{Triggered via /visual-tests · this comment is updated on every run for this platform.}

[nicoecheza]

/visual-tests

[m3taphysics]

PR #8860, run #26292885644

Builds: Windows change, Windows baseline, macOS change, macOS baseline

Framework 13 i7

Metric	Change	Baseline	Delta	Improvement
Samples	2701	2700
CPU average	33.3 ms	33.3 ms	-0.0 ms	0.0%	⚪
CPU 1% worst	33.9 ms	33.8 ms	0.0 ms	-0.1%	⚪
CPU 0.1% worst	38.7 ms	36.5 ms	2.2 ms	-6.0%	🔴
GPU average	8.1 ms	7.8 ms	0.2 ms	-3.0%	🔴
GPU 1% worst	18.8 ms	18.2 ms	0.6 ms	-3.2%	🔴
GPU 0.1% worst	25.5 ms	23.7 ms	1.7 ms	-7.3%	🔴

[claude]

Claude finished @pravusjif's task in 1m 28s —— View job

---

Claude Security Review — .github/workflows/visual-regression.yml

• Read CLAUDE.md
• Inspect .github/workflows/visual-regression.yml diff
• Read full workflow file for context
• Run security review (Step W)
• Post verdict

What this PR actually changes

Single-variable rename, both occurrences:

- vars.DEV_EXPLORER_TEAM_S3_BUCKET_PUBLIC_URL
+ vars.EXPLORER_TEAM_S3_BUCKET_PUBLIC_URL

(once in the documentation header at L23, once in the env: block at L94). The value is interpolated into the BUILD_URL used to download an existing Unity Cloud Build artifact from S3. No code execution path, no new secrets, no new tool surface introduced by the rename itself.

Step W findings on the change

Check	Status	Notes
W.1 prompt-from-checkout	N/A	No LLM in this workflow
W.2 heredoc delimiter on $GITHUB_OUTPUT	OK	Outputs use key=value form, no heredocs; HEAD_REF is a git ref so it cannot contain newlines
W.3 TOCTOU between trigger and run	OK for this dispatcher	gh api .../pulls/${PR_NUMBER} resolves the head at run time, but the head is only used to construct an artifact URL (no checkout/exec of PR code). Worst case a maintainer triggers a run against a newer commit than they read — annoying, not a secret-exfil channel
W.4 untrusted event text in prompt	N/A	comment.body is only matched with startsWith(...) in a GitHub expression; not shelled
W.5 destructive/exfil allowedTools	N/A	No allowedTools
W.6 actor gating	OK	OWNER|MEMBER|COLLABORATOR gate at L63–77 runs before any gh api call or reusable-workflow dispatch
W.8 pull_request_target	N/A	Trigger is issue_comment; no PR-code checkout
W.9 long-retention artifact	N/A	No upload-artifact here

Pre-existing items (not introduced by this PR — noted for tracking, do not block)

• W.7a — secret-holding reusable workflow pinned to a mutable ref. L162 uses decentraland/explorer-automation/.github/workflows/run-visual-suite.yml@main together with secrets: inherit (passing ALTTESTER_LICENSE, REPOS_READ_ONLY_TOKEN, DEV_EXPLORER_TEAM_S3_BUCKET, and the three DEV_EXPLORER_TEAM_AWS_* secrets). If explorer-automation's main is ever compromised the next /visual-tests invocation runs attacker code with all of those secrets in scope. Recommendation: pin to a 40-char commit SHA (and either Dependabot-manage it or document a manual review cadence). The inline comment at L159–161 explains the choice; SHA-pinning preserves the intent while removing the mutable-ref risk.
• W.10 — possibly overbroad permissions. The job-level scopes are contents: write and pull-requests: write. The dispatcher itself only posts an eyes reaction (covered by pull-requests: write) and reads PR metadata. contents: write is not exercised by anything in this file. It may be load-bearing for the reusable workflow, but reusable workflows receive permissions from their own permissions: block, not the caller's. Worth confirming and dropping if unused.

Neither item is caused by this PR's diff — flagging only because Step W asks me to surface them on any workflow touch.

Verdict

The variable rename is a benign config change; it repoints the dispatcher at a different S3 public-URL prefix and has no security impact on its own. The two pre-existing items above are worth a follow-up but should not block this PR.

DEPENDENCY_REVIEW: PASS
· branch test/trigger-visual-tests-2