[MCCProgrammer]

The bug

The first ZAP run failed: Permissions-Policy (#36) was in the Caddyfile on the server, but not in the site's answers.

• The deploy unpacks deploy/ with tar, which replaces Caddyfile with a new file (new inode).
• Caddy had the file mounted on its own (./Caddyfile:/etc/caddy/Caddyfile). A single-file bind mount stays on the inode it was given, so the container kept seeing the original file.
• On the server: the host file is inode 570816, while inside Caddy it is still 570815, without the header.
• So caddy reload in deploy.sh has re-read the first Caddyfile on every deploy. No Caddyfile change has ever reached the site.

The fix

• deploy/Caddyfile moves to deploy/caddy/Caddyfile, and Caddy mounts the folder (./caddy:/etc/caddy:ro). A folder mount shows the new file, so the reload, which drops no connections, reads it.
• The CI deploy copies caddy/ instead of Caddyfile.
• The monitoring job now also runs caddy validate on the Caddyfile, with the Caddy version from compose.yaml.
• The other files mounted one by one (backup.sh, offsite.sh) are fine: their containers are restarted on each deploy, and a restart mounts the new file.

Checks

• Reproduced in a Linux Docker (docker:dind), doing what the deploy does (tar, then caddy reload):
  • file mount: the site still answers with the old header;
  • folder mount: it answers with the new one.
• Docker Desktop on the Mac shows the new file in both cases, which is why the earlier local tests didn't catch this.
• caddy validate, actionlint and shellcheck pass.

After the merge

Compose recreates the Caddy container, because its mount changed. That means a few seconds without the site. The old /opt/extpulse/Caddyfile stays on the server unused and can be deleted. Once deployed, re-run the ZAP workflow.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud