fix(ci): dispatch the remaining pipelines by deploy target #692
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: konairius/homelab#692
Reference in New Issue
Block a user
Rollout des security-scan-Pilots auf die übrigen dreizehn. Closes #582.
Die Umstellung
Jedes Workflow-Root-Gate der Form
wird zu
Der Target kommt aus den Pipeline-Metadaten statt aus der Manual-Run-Variablen-Map und erreicht damit den Workflow-Root-Filter, was
PIPELINEunter 3.18 nicht tut.Am Piloten belegt: Pipeline 7004 (Event
deployment, Targetsecurity-scan) hat genau densecurity-scan-Workflow selektiert und keinen anderen.Zwei Dateien mit Step-level-Gates mussten mit
Sonst wären daraus Pipelines geworden, die zwar laufen, aber ihre Aufgabe nicht erledigen können:
deploy-infrastructure— der Apply-Step gated aufTOFU_APPLY. Aufevent: manualstehengelassen hätte er nie wieder gefeuert: die Pipeline hätte geplant und stillschweigend nie appliziert.TOFU_APPLYkommt jetzt über--param, was in derselben Nicht-Plugin-Umgebung landet, gegen die step-levelwhenauswertet. Kein Step in.woodpecker/benutztsettings:, also ist keiner ein Plugin — dieser Pfad trägt.build-ci-images— acht Pro-Image-Steps gaten auf manual-oder-push, um zu entscheiden, ob neu gebaut wird. Alle acht folgen dem Root (9 Vorkommen insgesamt, verifiziert).Cron-Gates unangetastet
Die matchten überall schon namentlich — außer bei
security-scan, was der Pilot behoben hat.Korrigierte Dokumentation
Unter anderem eine Behauptung in
update-audit.yml, die anderen Pipelines würden auf „an injectedPIPELINEvar set at cron-create time in the UI" gaten. Crons können überhaupt keine Variablen tragen —repo cron addnimmt name, branch, schedule, enabled. Der Satz beschrieb einen Mechanismus, den es nie gab, und war dasselbe Missverständnis, das den täglichen Security-Scan still nicht laufen ließ.Ebenfalls korrigiert:
MIGRATION-namespace.md:308, ein aktives Verifikations-Runbook, dessen Trigger-Befehl sonst ins Leere gelaufen wäre.Neue Bedienung
Voraussetzung ist
allow_deployauf dem Repo — von dir gesetzt, sonst 403 ausserver/api/pipeline.go:583.Geprüft
woodpecker-cli lint .woodpecker/— alle 17 Dateien valide. Die vierdeploy-*-Dateien werfen eine Warnung wegentimeout: 30auf Root-Ebene; die ist vorbestehend und bleibt unangetastet.Was ich nicht getestet habe
Nur
security-scanist real getriggert. Die anderen dreizehn sind eine mechanische, gleichförmige Ersetzung desselben Musters — aber getriggert habe ich sie nicht, und beideploy-infrastructurewürde ich den ersten Lauf bewusst mit Plan-only machen, bevor jemand-p TOFU_APPLY=truedranhängt.Closes #582
Rolls the security-scan pilot out to the other thirteen. Every workflow-root gate of the form - event: manual evaluate: 'PIPELINE == "x"' becomes - event: deployment evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "x"' The target rides in pipeline metadata rather than in the manual-run variable map, so it reaches the workflow-root filter on Woodpecker 3.18 where PIPELINE does not. Verified on the pilot: pipeline 7004 selected the security-scan workflow and nothing else. Two files also carry step-level manual gates, and those had to move with the root or the pipelines would have converted into something that runs but cannot do its job: deploy-infrastructure the apply step gates on TOFU_APPLY. Left on `event: manual` it would never fire again, so the pipeline would plan and silently never apply. TOFU_APPLY now arrives via `--param`, which lands in the same non-plugin environment step-level `when` evaluates against. No step here is a plugin — nothing in .woodpecker uses `settings:` — so that path holds. build-ci-images eight per-image steps gate on manual-or-push to decide whether to rebuild. All eight follow the root. Cron gates are untouched. They already matched by name everywhere except security-scan, which the pilot fixed. Also corrects the trigger documentation, including a claim in update-audit.yml that the other pipelines gate on "an injected PIPELINE var set at cron-create time in the UI". Crons cannot carry variables at all — `repo cron add` takes name, branch, schedule and enabled. That sentence described a mechanism that never existed and was the same misunderstanding that left the daily security scan silently not running. The `timeout: 30` lint warning on the four deploy-* files predates this and is left alone.🤖 Automated review — model
CLI default(complexity: complex), commitce86f7dc7f6e41b108585e282533a4545c2d4b72.Summary
Mechanical rollout of the
security-scan.ymlpilot pattern (event: manual+PIPELINE == "x"→event: deployment+CI_PIPELINE_DEPLOY_TARGET == "x") to the remaining 13 pipeline files, plus two step-level gate fixups (deploy-infrastructure's Tofu apply step,build-ci-images's 8 per-image steps) and doc corrections. I read every changed.woodpecker/*.ymlin the checkout and cross-checked against the already-convertedsecurity-scan.yml; the substitution is complete and consistent — no leftoverevent: manualorPIPELINE ==references remain anywhere in.woodpecker/, and the per-fileevaluatetarget string always matches the file's own pipeline name. No blocking issues found.🟡 Suggestions
.woodpecker/deploy-infrastructure.yml:86-88— theapplystep'swhen(event: deployment+evaluate: 'TOFU_APPLY == "true"') relies on a--parampassed topipeline deployreaching the same non-plugin step environment thatevaluatereads against. The PR body itself flags this as the one part of the rollout that was not exercised live (only thesecurity-scanroot-gate dispatch was verified against a real pipeline run). This step guardstofu applywith real infra credentials, so treat the "verified" language in the description with appropriate caution and confirm with a plan-only run before anyone passes-p TOFU_APPLY=true— which the PR body already recommends. Worth calling out explicitly in the PR discussion so it isn't lost before merge.Tests
No automated tests apply here (Woodpecker pipeline YAML + docs). The PR states
woodpecker-cli lint .woodpecker/passed on all 17 files with only a pre-existing, unrelatedtimeout: 30warning on the fourdeploy-*files. I independently verified the substitution's completeness via grep (no staleevent: manual/PIPELINE ==left) and confirmed thebuild-ci-images.ymlstep count (9 occurrences: 1 root + 8 per-image steps) matches what the PR body claims. I could not executewoodpecker-cli lintor trigger a real deployment myself in this environment, so I'm relying on static review plus the author's stated verification — the plan-only first run recommended in the PR body fordeploy-infrastructureis the right next validation step given the point above.Recommendation
Looks reasonable — no blocking issues; the suggestion above (verify
TOFU_APPLYstep-level gate with a plan-only first run) is already acknowledged by the author and worth keeping visible before anyone runs the real deploy.