Harden GitHub Actions workflows

[adamcohenhillel]

Summary

• Pin every third-party and first-party action across all five workflows to full commit SHAs (with # vX.Y.Z comments): checkout v4.3.1, setup-java v4.8.0, setup-node v4.4.0, upload-artifact v4.6.2, setup-android v3.2.2, gcp auth v2.1.13, setup-gcloud v2.2.1, action-gh-release v2.6.2.
• gcp-lab.yml: the pull_request_target: labeled path now verifies the label was applied by an actor with admin/maintain/write permission (via gh api .../collaborators/<actor>/permission) before doing anything else.
• release.yml: add a release-${{ inputs.version }} concurrency group (queued, never cancelled) and validate inputs.version against ^v?[0-9]+\.[0-9]+\.[0-9]+([-.][A-Za-z0-9.-]+)?$ as the first step of every job that interpolates it into shell.
• ci.yml: add ci-${{ github.ref }} concurrency (cancel-in-progress except on main/master) and a 60-minute job timeout.
• eval.yml: add a non-cancelling concurrency group so scheduled and manual runs cannot overlap on the single device runner.
• emulator.yml: remove the dead github.event_name != 'pull_request' guard (the workflow only triggers on push and workflow_dispatch).

Test plan

• CI workflow passes on this PR (checkout/setup pins resolve correctly)
• Apply run-gcp-lab label as a maintainer and confirm the GCP lab run proceeds
• Confirm a non-write actor applying the label causes the permission gate step to fail
• Run release.yml in dry-run mode with a valid version (e.g. v0.0.1) and confirm it passes
• Run release.yml with a malformed version (e.g. 1.0; rm -rf) and confirm the validation step fails
• Trigger emulator.yml via workflow_dispatch and confirm behavior is unchanged

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openphone-docs	Ready	Preview, Comment	Jul 2, 2026 1:02am

[adamcohenhillel]

Reviewed against latest origin/main (906a9123). This should stay open for rework; it is not mergeable right now.

Current blocker: the PR conflicts in .github/workflows/release.yml. Main has moved the release workflow substantially, so the version-validation, action pinning, and concurrency changes need to be replayed on the current release workflow shape.

Code review notes:

• Pinning actions to full SHAs is directionally good for workflow hardening.
• The gcp-lab.yml maintainer-permission gate is a useful defense for the pull_request_target label path.
• The removed emulator.yml pull_request guard is effectively dead in current main because that workflow is only workflow_dispatch, so I do not consider that part a blocker.

Because this touches release and cloud-lab workflows, please rerun/verify the workflow-specific cases after conflict resolution: normal CI, run-gcp-lab label by a maintainer, malformed release version rejection, valid dry-run release, and manual emulator dispatch.

[adamcohenhillel]

Closing this as superseded by current main plus later GCP/release workflow work.

A rebase is not the right move here anymore:

• The hard conflict is in .github/workflows/release.yml.
• The PR predates the newer GCP release flow from [codex] Enforce GCP release lab artifacts #108/[codex] Harden GCP release workflow cleanup #112 and would regress current gcp-release-build, run-release.sh, duplicate-release guard, cache discovery, cleanup, and artifact validation.
• The gcp-lab.yml changes are stale relative to the current lab lanes / skip_build / latest-cache-snapshot flow from [codex] Add GCP cache refresh lanes #114/[codex] Fix GCP cache refresh discovery #115.
• The action pinning is still worthwhile, but this branch only covers the old workflow set; current main also has gcp-cache-refresh.yml.

Replacement work should be split from latest main instead of preserving this diff:

1. Release input hardening for current release.yml.
2. GCP lab maintainer-label gate while preserving current lanes.
3. Optional action-SHA pinning across all current workflows.
4. Optional small workflow hygiene for CI/eval concurrency/timeouts.

No branch deletion here; this remains useful as historical reference.