Bug: update-kustomize-tag skipped when CI tests fail #405

New issue

Closed

opened 2026-04-08 22:21:04 +00:00 by forgejo_admin · 1 comment

forgejo_admin commented

2026-04-08 22:21:04 +00:00

Owner

Type

Bug

Lineage

Discovered during validation of #389 (PR #397). Pipeline #415 had a pre-existing test failure (enum assertion), which caused the entire pipeline to fail. The update-kustomize-tag step was skipped even though build-and-push succeeded. Result: image was pushed to Harbor but never propagated to ArgoCD. Same class of bug fixed in pal-e-platform PR #275.

Repo

forgejo_admin/basketball-api

What Broke

When any step in the pipeline fails (e.g., test), Woodpecker marks the pipeline as failed and skips remaining steps — even if update-kustomize-tag only depends on build-and-push (which succeeded). The tag update is silently skipped, so the new image never reaches ArgoCD. Merged code is not deployed.

This caused PR #397 (payment recovery feature) to be merged and pass CI image build, but never deployed to production.

Repro Steps

Merge a PR to main on basketball-api
Have a pre-existing test failure in the test suite (e.g., hardcoded enum assertion missing a new value)
Observe pipeline: test fails, build-and-push succeeds, update-kustomize-tag is skipped
Check ArgoCD — old image tag still deployed

Expected Behavior

update-kustomize-tag runs whenever build-and-push succeeds, regardless of whether test passed or failed.

Environment

Woodpecker CI, basketball-api pipeline, push to main.

File Targets

.woodpecker.yaml — add status: [success, failure] to the update-kustomize-tag step's when clause, so it runs as long as build-and-push completed (regardless of test step outcome).

Acceptance Criteria

update-kustomize-tag step includes status: [success, failure] in its when clause
Step still only runs on push to main
Step still depends on build-and-push

Test Expectations

YAML must be valid (parse with python3 -c "import yaml; yaml.safe_load(open('.woodpecker.yaml'))")
Verify by inspecting the diff — this is a CI config change, not application code

Constraints

Match the pattern from pal-e-platform PR #275 / scripts/woodpecker-update-tag-step.yaml
Do NOT change any other steps
Per feedback_yaml_parse_validation: agent MUST parse-validate the YAML before committing

Checklist

PR opened
YAML validated
No unrelated changes

pal-e-platform PR #275 (same fix for the reference template)
Blocked: #389 validation (image 16b96f5 never deployed)

### Type Bug ### Lineage Discovered during validation of #389 (PR #397). Pipeline #415 had a pre-existing test failure (enum assertion), which caused the entire pipeline to fail. The `update-kustomize-tag` step was skipped even though `build-and-push` succeeded. Result: image was pushed to Harbor but never propagated to ArgoCD. Same class of bug fixed in pal-e-platform PR #275. ### Repo `forgejo_admin/basketball-api` ### What Broke When any step in the pipeline fails (e.g., `test`), Woodpecker marks the pipeline as failed and skips remaining steps — even if `update-kustomize-tag` only depends on `build-and-push` (which succeeded). The tag update is silently skipped, so the new image never reaches ArgoCD. **Merged code is not deployed.** This caused PR #397 (payment recovery feature) to be merged and pass CI image build, but never deployed to production. ### Repro Steps 1. Merge a PR to main on basketball-api 2. Have a pre-existing test failure in the test suite (e.g., hardcoded enum assertion missing a new value) 3. Observe pipeline: `test` fails, `build-and-push` succeeds, `update-kustomize-tag` is skipped 4. Check ArgoCD — old image tag still deployed ### Expected Behavior `update-kustomize-tag` runs whenever `build-and-push` succeeds, regardless of whether `test` passed or failed. ### Environment Woodpecker CI, basketball-api pipeline, push to main. ### File Targets - `.woodpecker.yaml` — add `status: [success, failure]` to the `update-kustomize-tag` step's `when` clause, so it runs as long as `build-and-push` completed (regardless of test step outcome). ### Acceptance Criteria - [ ] `update-kustomize-tag` step includes `status: [success, failure]` in its `when` clause - [ ] Step still only runs on push to main - [ ] Step still depends on `build-and-push` ### Test Expectations - YAML must be valid (parse with `python3 -c "import yaml; yaml.safe_load(open('.woodpecker.yaml'))"`) - Verify by inspecting the diff — this is a CI config change, not application code ### Constraints - Match the pattern from pal-e-platform PR #275 / `scripts/woodpecker-update-tag-step.yaml` - Do NOT change any other steps - Per `feedback_yaml_parse_validation`: agent MUST parse-validate the YAML before committing ### Checklist - [ ] PR opened - [ ] YAML validated - [ ] No unrelated changes ### Related - pal-e-platform PR #275 (same fix for the reference template) - Blocked: #389 validation (image `16b96f5` never deployed)

forgejo_admin commented

2026-04-08 22:22:47 +00:00

Author

Owner

Scope Review: READY

Review note: review-901-2026-04-08

Scope is solid. 1-file YAML change, 3 verifiable ACs, matches pal-e-platform PR #275 pattern. File target verified — .woodpecker.yaml lines 60-83 confirmed missing status: [success, failure].

Blast radius discovered: westside-app, pal-e-docs, and pal-e-app have the same bug. Recommend separate issues for each.

## Scope Review: READY Review note: `review-901-2026-04-08` Scope is solid. 1-file YAML change, 3 verifiable ACs, matches pal-e-platform PR #275 pattern. File target verified — `.woodpecker.yaml` lines 60-83 confirmed missing `status: [success, failure]`. **Blast radius discovered:** westside-app, pal-e-docs, and pal-e-app have the same bug. Recommend separate issues for each.