Files
a88bf2c5a5 chore(web): harden CI permissions and expose /version.json (#7918)
* chore(ci): set default workflow permissions to none

Workflows previously missing a top-level permissions block inherit the
default GITHUB_TOKEN with write access. Set permissions: {} at the
workflow level so each job must declare what it needs. For two jobs
that lacked explicit permissions, grant contents: read so checkout
still works.

* feat(web): expose build metadata at /version.json

Generate apps/web/public/version.json during the build with the package
version, commit SHA, optional git tag, branch, and build time. After
deploy, the served bundle exposes /version.json so the running
release can be identified without dashboard access — useful for
external monitoring that compares the live deploy against the latest
GitHub release. The generated file is gitignored.

* chore(ci): address review comments — explicit contents:read + accurate version SHA

- Add `contents: read` to jobs in web-checks.yml (lint/prettier/type-check/
  knip-exports), web-deploy-dev.yml (deploy), and tx-builder-deploy.yml
  (pr-preview, deploy-staging). With workflow-level `permissions: {}`,
  these jobs no longer inherit the contents scope that actions/checkout
  relies on; granting it explicitly removes the ambiguity.
- generate-version.mjs: prefer `git rev-parse HEAD` over `GITHUB_SHA`.
  On pull_request events `GITHUB_SHA` is the merge commit, but the deploy
  workflow checks out `pull_request.head.sha` — the script was reporting
  the wrong SHA. Also use `GITHUB_HEAD_REF` for PR branch resolution
  (`GITHUB_REF_NAME` is "<N>/merge" on PRs) and filter detached "HEAD"
  out of the git fallback for tag builds.

---------

Co-authored-by: Hanzo Dev <[email protected]>
2026-05-26 13:54:22 +02:00
..
2025-11-18 17:46:09 +01:00
…