Bug: Apply step exit code capture broken — lock detection is dead code #151

New issue

Closed

opened 2026-03-24 20:05:27 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-03-24 20:05:27 +00:00

Owner

Type

Bug

Lineage

standalone — discovered during pipeline failure investigation (session 2026-03-24)

Repo

forgejo_admin/pal-e-platform

What Broke

In .woodpecker.yaml line 193, the apply step uses a subshell piped to tee:

(tofu apply ... 2>&1; echo $? > /tmp/apply-exit) | tee /tmp/apply-output.txt
APPLY_EXIT=$(cat /tmp/apply-exit)

When tofu apply fails, the subshell's echo $? never executes — the pipe kills the left-side subshell before it reaches the echo. /tmp/apply-exit is never created.

Error in CI logs: cat: can't open '/tmp/apply-exit': No such file or directory

This makes the lock detection logic (lines 196-209) dead code — it's never reached. Subsumes #136.

Repro Steps

Merge any PR to main that triggers a tofu apply
If apply encounters ANY error (Helm stuck, field manager, etc.)
Observe: step fails with "can't open /tmp/apply-exit" instead of running lock detection

Expected Behavior

Exit code captured correctly
Lock detection logic fires when state lock errors occur
Step reports the actual apply error, not a missing file error

Environment

Cluster/namespace: woodpecker CI pods
Service version/commit: current main (HEAD)
Related alerts: Pipelines #235, #239 both show this failure

Acceptance Criteria

Apply step captures exit code correctly in POSIX sh (no PIPESTATUS)
Lock detection logic is reachable on state-lock errors
CI log still shows full apply output
Step exits with correct code on non-lock failures

project-pal-e-platform — platform CI
forgejo_admin/pal-e-platform #136 — dead force-unlock block (subsumed by this fix)
forgejo_admin/pal-e-platform #137 — Woodpecker secret drift (also causes apply failures)

### Type Bug ### Lineage standalone — discovered during pipeline failure investigation (session 2026-03-24) ### Repo `forgejo_admin/pal-e-platform` ### What Broke In `.woodpecker.yaml` line 193, the apply step uses a subshell piped to tee: ```sh (tofu apply ... 2>&1; echo $? > /tmp/apply-exit) | tee /tmp/apply-output.txt APPLY_EXIT=$(cat /tmp/apply-exit) ``` When `tofu apply` fails, the subshell's `echo $?` never executes — the pipe kills the left-side subshell before it reaches the echo. `/tmp/apply-exit` is never created. Error in CI logs: `cat: can't open '/tmp/apply-exit': No such file or directory` This makes the lock detection logic (lines 196-209) dead code — it's never reached. Subsumes #136. ### Repro Steps 1. Merge any PR to main that triggers a `tofu apply` 2. If apply encounters ANY error (Helm stuck, field manager, etc.) 3. Observe: step fails with "can't open /tmp/apply-exit" instead of running lock detection ### Expected Behavior - Exit code captured correctly - Lock detection logic fires when state lock errors occur - Step reports the actual apply error, not a missing file error ### Environment - Cluster/namespace: woodpecker CI pods - Service version/commit: current main (HEAD) - Related alerts: Pipelines #235, #239 both show this failure ### Acceptance Criteria - [ ] Apply step captures exit code correctly in POSIX sh (no PIPESTATUS) - [ ] Lock detection logic is reachable on state-lock errors - [ ] CI log still shows full apply output - [ ] Step exits with correct code on non-lock failures ### Related - `project-pal-e-platform` — platform CI - `forgejo_admin/pal-e-platform #136` — dead force-unlock block (subsumed by this fix) - `forgejo_admin/pal-e-platform #137` — Woodpecker secret drift (also causes apply failures)