A Test Environment for Releases
Approving a release is its promotion to test. The approval tags a release candidate on each of its repositories, with the approver’s own GitHub account, and a generated test workflow deploys it behind the passport check, so whatever runs against the test deployment can report its result before the release goes to production.
What approval does
Once a release is approved and its passport issued, the Studio tags each repository of the release at the commit the approval pinned: rc/REL-12 at the first approval, rc/REL-12.2 at the next, and so on. The tag is made with the approver’s own GitHub account — never the GitHub App and never the connection’s token — and the release page lists it under Release candidate.
The test workflow
Where a part of the repository deploys, Repositories → DevOps → Create offers a test pipeline beside dev and prod. It runs on rc/ tags:
| Job | What it does |
|---|---|
build-test | Builds and runs the unit tests |
scan | Scans the candidate by what each part is |
report-checks | Reports the results for the tagged commit, which is the release’s cut: they count at the production promotion |
passport-check | Verifies the release’s signed passport for the test environment, enforced by default; the owner can choose warn only in the proposal |
deploy-test | Runs the check again as its first step, checks the tagged commit is on the default branch, deploys to test and reports the deployment |
On GitHub, before the first candidate
- Create the
testenvironment (Settings → Environments) with its own secrets and its own cloud identity, scoped to that environment. - Limit its deployments to
rc/*tags. - Protect
rc/*tags as you protectv*ones, with a tag ruleset, so only the people who approve releases can make them.
The deploy token is the same repository secret, PW_DEPLOY_TOKEN.
A dynamic scan against the test deployment
No dynamic scan is generated. Point your own tool — OWASP ZAP, for example — at the test deployment from a workflow of your own on the same rc/ tag, and report its result as the dast category for the tagged commit, as in Tests and Scans on the Passport. A delivery policy that asks for a dynamic scan at the production promotion, at the release’s cut and always, then finds it when the release is released, and refuses the release until it is there.
What it costs
One run of the test workflow per approval: a build, one scan, the report and the deploy — about what a push to main costs, plus the deploy.