Root cause of Woodpecker push pipelines silently no-op'ing since
2026-07-18: Woodpecker's config resolution is
.woodpecker/*.{yaml,yml} -> .woodpecker.yaml -> .woodpecker.yml
Once .woodpecker/renovate.yml existed, the root .woodpecker.yml was
entirely ignored. Every push webhook hit renovate.yml's `when: event:
cron` filter, matched zero steps, and Woodpecker logged
"ignoring hook: 'when' filters filtered out all steps" instead of
running deploy.
Moving the push pipeline into .woodpecker/deploy.yml restores it as
an independent workflow alongside renovate.yml -- each file's own
`when:` filter now applies correctly (push -> deploy.yml, cron ->
renovate.yml).
Adds powerautomate entry with Azure app registration credentials.
Auth dir (/volume1/docker/mcpo/powerautomate-auth/) and config stub
already exist on host from prior session.
NOTE: powerautomate-mcp package not yet on npm - npx will fail until
published. Tracked here for GitOps pipeline; will update command when
package is available or we switch to build-from-source approach.
- Pin ms365 to 0.129.0 with --discovery flag (fixes MCPO schema parse error)
- Add powerautomate entry (PA_MCP_CLIENT_ID placeholder - needs Azure app reg)
- Update authentik token (was expired)
- teams-mcp-auth volume now source of truth for ms365/teams auth cache
- powerautomate-auth volume wired for future PA auth cache
NOTE: config.json was previously managed manually on disk only.
This commit brings it under GitOps control.
reverse-proxy publishes host-mode ports (80/443/1883/5201/5431) — start-first
can never bind while the old task holds the ports, deadlocking every rolling
update. keepalived master/backup run VRRP on the host network — concurrent
old+new speakers with the same router-id risk VIP flapping. Both now use
stop-first (global mode + parallelism=1 + VIP failover keeps ingress up).
Stateless helpers (whoami, speedtest, iperf3, certs-dumper) keep start-first.
Step 1 of Tier 0/1 pipeline inclusion (prep for removing traefik/woodpecker
from the bootstrap manual-deploy guard).
Image ghcr.io/thebluffman85/crowdsec-web-ui:latest never existed (typo in org name).
Correct upstream project is TheDuffman85/crowdsec-web-ui on GitHub. Fixed to
ghcr.io/theduffman85/crowdsec-web-ui:latest.
Deployed and verified live on docker-2 prior to this commit:
- security_crowdsec-web-ui now pulls successfully and is Running
- Host(`secure.bryanmail.net`) rule intact, all CROWDSEC_* env vars correct
- security_crowdsec unaffected, still running
Docker secrets (postgresql_password, postgresql_pgadmin_password) already handled
POSTGRES_PASSWORD_FILE/PGADMIN_DEFAULT_PASSWORD_FILE. This removes the two remaining
`env_file: - postgresql.env` lines (postgresql + pgadmin services) which were redundant
and left the stack in a half-migrated hybrid state. Non-secret vars (POSTGRES_USER,
PGADMIN_DEFAULT_EMAIL, DATABASUS_HOST, PGADMIN_HOST) continue to be supplied via
stack-deploy.sh's envsubst mechanism from postgresql.env at deploy time — no functional
change to those values.
Deployed and verified live on docker-2 prior to this commit:
- postgresql_postgresql: pg_isready OK, all 21 databases intact, psql auth via Docker secret confirmed
- postgresql_pgadmin: Host(`dba.bryanmail.net`) rule + PGADMIN_DEFAULT_EMAIL correct
- postgresql_databasus: running
- All dependent stacks (mealie, vaultwarden, auth, media, homeassistant, guacamole, security) remained healthy throughout, zero reconnect issues
admin
AVB