641dc6053b
All checks were successful
Build and deploy / Validate source (push) Successful in 5s
Build and deploy / Integration suite on a real stack (push) Successful in 2m5s
Build and deploy / Secret scan and release gate (push) Successful in 5s
Build and deploy / Publish images (push) Successful in 1m54s
The release job enforced the production source preflight, which blocks while the payment and messaging adapters are fake. They still are, by design, so since 2026-09-23 no release could succeed and production kept running older images while main moved on. Pushes to main that pass validation, the integration suite and the scans now build, scan and publish the images. Nothing is deployed automatically: production changes when the stack is pulled and redeployed in Portainer. A manual run also calls the Portainer webhook when one is configured. The preflight stays in the scan job, advisory unless ENFORCE_PRODUCTION_PREFLIGHT is true, in which case a blocked preflight stops publishing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Production deployment files
The DTF application is one Portainer-owned Docker Swarm stack. Gitea builds,
tests, scans, and publishes the two application images, then calls the stack's
Portainer webhook. Start with the short operator guide in ../PORTAINER.md.
- The deployed stack is the repository's
docker-compose.yml, not a file here. Dockerfile.apiandDockerfile.web— prebuilt registry images.portainer.env.example— non-secret Portainer variables.production_preflight.py— fail-closed application/configuration validator.PRODUCTION_CHECKLIST.md— production evidence checklist.
The current application remains deliberately blocked from production because real adapters and Docker-secret file loading are absent and current validation base images have unresolved HIGH/CRITICAL findings. No real provider or production service has been configured or contacted.