UnescapedWoodpeckerVar check only scans step commands: text, but Woodpecker substitutes ${VAR} over the WHOLE raw pipeline file #13

Closed
opened 2026-08-03 20:08:27 +03:00 by issuer-agent · 0 comments

While fixing oleks/pipetree#11's flagged findings on oleks/deals (PR oleks/deals#8), I added an explanatory YAML comment ABOVE (not inside) a step's commands: block that itself contained literal, unescaped ${...} and ${VAR} example text (a genuine mistake, ironic given the topic). pipetree's -analyze detector did NOT flag this (it only scans parsed Commands strings per internal/analyze/footguns.go's findUnescapedVars, which walks s.Commands for each step — plain YAML # comment lines between/around commands list items aren't part of any command string, so they're invisible to the check).

But live Woodpecker (v3.15.0, git.oleks.space instance) DID choke on it: pushing that commit produced a hard pipeline COMPILE failure, status "error", message "unable to parse variable name" (Woodpecker pipeline #12 and #13 on oleks/deals, also reproduced identically on oleks/element-web-patched pipelines #5/#6). This proves Woodpecker's ${VAR} substitution pass runs over the ENTIRE raw pipeline YAML text — including comment lines that live outside any commands: string — not just inside command bodies. Once the comment was rewritten to avoid any literal ${ sequence, the next push (oleks/element-web-patched pipeline #7) compiled and ran fine.

Ask: widen findUnescapedVars (or add a parallel raw-text pass) to scan the FULL raw pipeline file text for ${VAR} patterns outside commands: too — step names, top-level comments, environment: values, etc — not just parsed command strings, since that's what Woodpecker itself actually substitutes over. Otherwise the detector has a real false-negative gap: it can pass a file clean that Woodpecker will still refuse to compile. Reference oleks/pipetree#11 and this fix session (PRs on oleks/deals#8, oleks/element-web-patched#2, oleks/terminal-agent#1) as the reproduction.

While fixing oleks/pipetree#11's flagged findings on oleks/deals (PR https://git.oleks.space/oleks/deals/pulls/8), I added an explanatory YAML comment ABOVE (not inside) a step's `commands:` block that itself contained literal, unescaped `${...}` and `${VAR}` example text (a genuine mistake, ironic given the topic). pipetree's `-analyze` detector did NOT flag this (it only scans parsed `Commands` strings per `internal/analyze/footguns.go`'s `findUnescapedVars`, which walks `s.Commands` for each step — plain YAML `#` comment lines between/around commands list items aren't part of any command string, so they're invisible to the check). But live Woodpecker (v3.15.0, git.oleks.space instance) DID choke on it: pushing that commit produced a hard pipeline COMPILE failure, status "error", message "unable to parse variable name" (Woodpecker pipeline #12 and #13 on oleks/deals, also reproduced identically on oleks/element-web-patched pipelines #5/#6). This proves Woodpecker's `${VAR}` substitution pass runs over the ENTIRE raw pipeline YAML text — including comment lines that live outside any `commands:` string — not just inside command bodies. Once the comment was rewritten to avoid any literal `${` sequence, the next push (oleks/element-web-patched pipeline #7) compiled and ran fine. Ask: widen `findUnescapedVars` (or add a parallel raw-text pass) to scan the FULL raw pipeline file text for `${VAR}` patterns outside `commands:` too — step names, top-level comments, `environment:` values, etc — not just parsed command strings, since that's what Woodpecker itself actually substitutes over. Otherwise the detector has a real false-negative gap: it can pass a file clean that Woodpecker will still refuse to compile. Reference oleks/pipetree#11 and this fix session (PRs on oleks/deals#8, oleks/element-web-patched#2, oleks/terminal-agent#1) as the reproduction.
oleks closed this issue 2026-08-04 01:02:51 +03:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: oleks/pipetree#13