Recovery editor note + refresh CI action pins + scaffold M15 merge (#43,#44,#50) (#66)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>
This commit was merged in pull request #66.
This commit is contained in:
2026-06-22 17:30:41 -04:00
committed by Claude (agent)
parent 315cb2c190
commit 3f096c71ff
8 changed files with 74 additions and 18 deletions
+55 -4
View File
@@ -337,10 +337,57 @@ runs on every push and blocks the merge.
each non-zero exit. Re-apply your Part B/C fixes (and re-stage), run it once more, and it should
pass.
2. Add a security step to your pipeline that calls it. `lab/ci-security.yml` is a provider-neutral
snippet — a job that installs the scanners and runs the script. Slot its steps into the workflow
you built in Module 14 (the exact YAML keys follow whatever host that module used; the *shape* —
install tools, run the gate, fail on findings — is identical everywhere).
2. Merge the security steps into your pipeline. `lab/ci-security.yml` shows the gate as a
self-contained, provider-neutral job — check out, set up Python, install the scanners, run the
script. But the `check` job you built in Module 14 *already* checks out the code and sets up
Python, so you don't want a second job duplicating that work. You want its two **new** steps —
**install the scanners** and **run the gate** — added to the steps you already have. (Checkout and
Python are in the snippet only so it reads as a complete example; skip them when you merge.)
Here is exactly where they go. **Before** — the tail of your Module 14 `check` job (GitHub Actions
flavor, matching `ci-starter.yml`; on GitLab the same two steps drop into the job's `script:`):
```yaml
jobs:
check:
runs-on: ubuntu-latest
steps:
- name: Check out the code
uses: actions/checkout@v7
- name: Set up Python
uses: actions/setup-python@v6
with:
python-version: "3.12"
- name: Install tools
run: pip install ruff
- name: Lint
run: ruff check .
- name: Test
run: python -m unittest
```
**After** — the same job with the two security steps appended; nothing else changes:
```diff
- name: Lint
run: ruff check .
- name: Test
run: python -m unittest
+ - name: Install scanners
+ run: pip install pip-audit detect-secrets
+ - name: Run the security gate
+ run: |
+ chmod +x security-scan.sh
+ ./security-scan.sh
```
> **YAML is indentation-sensitive — match the existing steps' indentation exactly.** Each new
> `- name:` lines up in the *same column* as the steps above it, and the keys under it (`run:`) sit
> one level deeper. A step pasted even one space off will silently attach to the wrong block or
> fail to parse, and the whole workflow breaks. If you'd rather keep the gate as its own job (some
> teams prefer the isolation), copy `ci-security.yml` in whole as a second job under `jobs:` in the
> same workflow file instead — that is exactly why it carries its own checkout and Python steps.
> The *shape* — install tools, run the gate, fail on findings — is identical everywhere.
3. Prove the gate has teeth: re-introduce the hardcoded key in `config.py`, commit, and push. Watch
the pipeline go **red** on the security step even though lint, build, and tests are still green.
@@ -401,6 +448,10 @@ reproducible.
> **Expansion-zone module — these facts move fast.** Re-check at build/publish time; don't ship the
> claims above from memory.
- [ ] **Pinned CI action versions.** The `ci-security.yml` snippet (and the Part D before/after diff)
pin `actions/checkout` and `actions/setup-python` to major versions (`@v7`/`@v6` at build time).
Pinned majors age — confirm they're current and not deprecated against the host's docs, the same
check the Module 14 and Module 18 CI/CD checklists carry.
- [ ] **Scanner names and install methods.** Confirm `pip-audit`, `detect-secrets`, and `bandit` are
still maintained and still install as shown. If any has stalled, swap in a current equivalent
from the *same category* and keep the prose category-first, not tool-first.