From e314ab19d6961ef8bca48b1b1f8e58d5089afe12 Mon Sep 17 00:00:00 2001 From: Philip Hartlieb Date: Fri, 6 Nov 2026 15:15:36 -0500 Subject: [PATCH] README: put the secret-mapping note back under the example it refers to #11 inserted the dev-security caller between the secrets example and "map it by name as above", so that sentence pointed at a block with no secrets (review note V12 on #12). Text unchanged; only its position moves. --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 8d5c430..8d6e89e 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,11 @@ jobs: Use the SHA of a `v*` tag of this repository, never a branch. Tags here are created only by the release App and can't be moved or deleted, so a version comment always matches its SHA. +`release-check.yml` and `publish.yml` read the release App key in jobs that run in the caller's `release` +environment. A reusable workflow gets an environment secret only when the caller passes it, so map it by +name as above, alongside any other secrets such as `registry-token`. The caller's own job can't read the +value; GitHub supplies it inside the environment. + Call `dev-security.yml` from a workflow that runs on `pull_request`, with a job named `dev-security`, so the checks a `dev` ruleset requires are `dev-security / dependency-review` and `dev-security / workflow-lint`: @@ -45,11 +50,6 @@ jobs: uses: blacklanternsecurity/release-workflows/.github/workflows/dev-security.yml@ # v1.1.0 ``` -`release-check.yml` and `publish.yml` read the release App key in jobs that run in the caller's `release` -environment. A reusable workflow gets an environment secret only when the caller passes it, so map it by -name as above, alongside any other secrets such as `registry-token`. The caller's own job can't read the -value; GitHub supplies it inside the environment. - ## How changes land - `dev`: pull request, required tests and security checks (CodeQL, dependency review, `actionlint`,