Fixes the ERROR: No main compose file (deploy.yml or deploy.yaml) in /volume1/docker/compose-files/deploy / FAIL deploy failure seen when merging PR #8.
Root cause
grep -E '^[^/.][^/]*/' (used to detect folder-based stacks from the changed-files list) matches any non-dot top-level folder — including deploy/, the shared tooling folder that every stack's deploy already depends on. It was never meant to be treated as a deployable stack itself.
PR #8 only touched deploy/envparse.py. That was enough for cut -d/ -f1 to extract deploy as a "changed stack," which then got passed to stack-deploy.sh deploy — which correctly errored, since there's no deploy/deploy.yaml.
Impact
No live service was affected. The error occurs in stack-deploy.sh before any docker stack deploy runs — confirmed by checking ai_litellm's UpdatedAt timestamp, unchanged across this failure. The practical harm was a confusing FAIL on an otherwise-correct, already-synced change (deploy/envparse.py's corrected content had already been rsynced to disk successfully in the same run, before the false "deploy" stack was processed).
Fix
Added | grep -v '^deploy$' immediately after the folder-name extraction, in all 5 places this exact pattern appears: validate, provision-secrets (×2 — the guard-check block and the main provisioning loop), deploy, verify. deploy/ is still unconditionally rsynced at the top of the deploy step regardless of which stacks changed — this only stops it from being treated as a stack to deploy.
Scope
One file, .woodpecker/deploy.yml. No changes to any stack's compose file, secrets, or envparse.py/stack-deploy.sh logic.
Verification after merge
Push a trivial change under deploy/ only (or re-trigger PR #8's merge commit) and confirm the pipeline completes without a spurious deploy stack entry — should just show the deploy/ sync and then move on cleanly (no stacks actually redeployed, since no stack folder changed).
## What
Fixes the `ERROR: No main compose file (deploy.yml or deploy.yaml) in /volume1/docker/compose-files/deploy` / `FAIL deploy` failure seen when merging PR #8.
## Root cause
`grep -E '^[^/.][^/]*/'` (used to detect folder-based stacks from the changed-files list) matches **any** non-dot top-level folder — including `deploy/`, the shared tooling folder that every stack's deploy already depends on. It was never meant to be treated as a deployable stack itself.
PR #8 only touched `deploy/envparse.py`. That was enough for `cut -d/ -f1` to extract `deploy` as a "changed stack," which then got passed to `stack-deploy.sh deploy` — which correctly errored, since there's no `deploy/deploy.yaml`.
## Impact
**No live service was affected.** The error occurs in `stack-deploy.sh` before any `docker stack deploy` runs — confirmed by checking `ai_litellm`'s `UpdatedAt` timestamp, unchanged across this failure. The practical harm was a confusing `FAIL` on an otherwise-correct, already-synced change (`deploy/envparse.py`'s corrected content had already been rsynced to disk successfully in the same run, before the false "deploy" stack was processed).
## Fix
Added `| grep -v '^deploy$'` immediately after the folder-name extraction, in all 5 places this exact pattern appears: `validate`, `provision-secrets` (×2 — the guard-check block and the main provisioning loop), `deploy`, `verify`. `deploy/` is still unconditionally rsynced at the top of the `deploy` step regardless of which stacks changed — this only stops it from being *treated as a stack to deploy*.
## Scope
One file, `.woodpecker/deploy.yml`. No changes to any stack's compose file, secrets, or `envparse.py`/`stack-deploy.sh` logic.
## Verification after merge
Push a trivial change under `deploy/` only (or re-trigger PR #8's merge commit) and confirm the pipeline completes without a spurious `deploy` stack entry — should just show the deploy/ sync and then move on cleanly (no stacks actually redeployed, since no stack folder changed).
grep -E '^[^/.][^/]*/' matches ANY non-dot top-level folder in the
changed-files list, including deploy/ -- the shared tooling folder
synced by every deploy, not a stack. A PR touching only
deploy/envparse.py caused stack-deploy.sh to be invoked with "deploy"
as a stack name, which correctly errored ("No main compose file... in
.../deploy") since deploy/ has no deploy.yaml.
No live service was affected (the error occurs before any redeploy
attempt), but it produced a confusing FAIL on an otherwise-correct
change (PR #8) and could mask a real failure in the noise.
Adds `| grep -v '^deploy$'` after the folder-name extraction in all 5
places this pattern appears (validate, provision-secrets x2, deploy,
verify). deploy/ is already unconditionally rsynced at the top of the
deploy step regardless of which stacks changed, so excluding it from
the stack list is safe -- it will still be synced, just never treated
as a deployable stack.
AVB
merged commit 808483181b into main2026-08-26 21:13:41 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
Fixes the
ERROR: No main compose file (deploy.yml or deploy.yaml) in /volume1/docker/compose-files/deploy/FAIL deployfailure seen when merging PR #8.Root cause
grep -E '^[^/.][^/]*/'(used to detect folder-based stacks from the changed-files list) matches any non-dot top-level folder — includingdeploy/, the shared tooling folder that every stack's deploy already depends on. It was never meant to be treated as a deployable stack itself.PR #8 only touched
deploy/envparse.py. That was enough forcut -d/ -f1to extractdeployas a "changed stack," which then got passed tostack-deploy.sh deploy— which correctly errored, since there's nodeploy/deploy.yaml.Impact
No live service was affected. The error occurs in
stack-deploy.shbefore anydocker stack deployruns — confirmed by checkingai_litellm'sUpdatedAttimestamp, unchanged across this failure. The practical harm was a confusingFAILon an otherwise-correct, already-synced change (deploy/envparse.py's corrected content had already been rsynced to disk successfully in the same run, before the false "deploy" stack was processed).Fix
Added
| grep -v '^deploy$'immediately after the folder-name extraction, in all 5 places this exact pattern appears:validate,provision-secrets(×2 — the guard-check block and the main provisioning loop),deploy,verify.deploy/is still unconditionally rsynced at the top of thedeploystep regardless of which stacks changed — this only stops it from being treated as a stack to deploy.Scope
One file,
.woodpecker/deploy.yml. No changes to any stack's compose file, secrets, orenvparse.py/stack-deploy.shlogic.Verification after merge
Push a trivial change under
deploy/only (or re-trigger PR #8's merge commit) and confirm the pipeline completes without a spuriousdeploystack entry — should just show the deploy/ sync and then move on cleanly (no stacks actually redeployed, since no stack folder changed).grep -E '^[^/.][^/]*/' matches ANY non-dot top-level folder in the changed-files list, including deploy/ -- the shared tooling folder synced by every deploy, not a stack. A PR touching only deploy/envparse.py caused stack-deploy.sh to be invoked with "deploy" as a stack name, which correctly errored ("No main compose file... in .../deploy") since deploy/ has no deploy.yaml. No live service was affected (the error occurs before any redeploy attempt), but it produced a confusing FAIL on an otherwise-correct change (PR #8) and could mask a real failure in the noise. Adds `| grep -v '^deploy$'` after the folder-name extraction in all 5 places this pattern appears (validate, provision-secrets x2, deploy, verify). deploy/ is already unconditionally rsynced at the top of the deploy step regardless of which stacks changed, so excluding it from the stack list is safe -- it will still be synced, just never treated as a deployable stack.