# Overview

Re-enables the `build-and-test-templates` CI job, disabled in #16371
while it required a published 4.x release of the workspace packages on
npm.

The job now builds templates against fully local packages and runs
non-blocking, so it surfaces template breakage on 4.x without gating
PRs.

## Key Changes

- **Re-enabled the job, non-blocking**
- Restored `if: needs.changes.outputs.needs_build == 'true'` (was `if:
false`) and added `continue-on-error: true`, matching the existing
`tests-content-api` pattern. Failures show up in CI but do not fail the
`all-green` gate until templates are updated for 4.x breaking changes.

- **Made the local package install hermetic**
- The build now packs all workspace packages (`script:pack --all`) and
rewrites `build-template-with-local-pkgs` to point every `@payloadcms/*`
(and `payload`) dependency at its local `file:` tarball, in both the
dependency entries and `pnpm.overrides`, before a single install.

## Design Decisions

The previous flow ran `pnpm add ./*.tgz` before setting overrides. That
first install resolved the tarballs' internal cross-dependencies
(`@payloadcms/translations`, `@payloadcms/plugin-cloud-storage`, and
others) from npm at the in-repo version, which during 4.x beta is
unpublished, so it failed with `ERR_PNPM_NO_MATCHING_VERSION`. That is
what kept the job disabled.

Setting `file:` overrides for the full set of packed packages up front
forces every workspace dependency, direct and transitive, to resolve to
a local tarball. The install no longer touches npm for any `@payloadcms`
package, so the job works regardless of what is published. This mirrors
the approach already used by `test/setupProd.ts` for the prod E2E job.

Templates still pin the 3.x config API (for example, storage adapters
passed to `plugins` rather than the 4.x `storage` array), so the builds
currently fail once packages resolve. Running the job non-blocking
surfaces that work without holding up merges; the `continue-on-error`
flag comes off once the templates are migrated.