536510b148
All checks were successful
Build and deploy / Validate source (push) Successful in 7s
Build and deploy / Integration suite on a real stack (push) Successful in 2m9s
Build and deploy / Secret scan and release gate (push) Successful in 6s
Build and deploy / Publish images (push) Successful in 1m44s
The proxy in front of production caches .js and .css for hours. After the last release the Site got the new index.html with the old site-flow.js, which wrote to an element the new page no longer has; the error left "Adicionar ao carrinho" disabled. The web build now addresses every local script and stylesheet by a hash of its content, replacing the hand-kept ?v= markers, so a new release always loads its own files. 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.