andreandClaude Sonnet 5
0ea8eb1cde
config/cache/ e assets/img/seo/ passaram a volumes próprios
(/srv/data/fitme.andmore.pt/{cache,seo}), mas o checkout continua
664/2775: o deploy-on-push corre como www-data dentro do pedido do
webhook, não como deploy, e 644/2755 partiu a primeira push a seguir
("Permission denied" a criar um ficheiro novo). Documentado para a
próxima vez que alguém for tentar isto outra vez.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.2 KiB
shared/platform-tools is a git submodule (again)
Was vendored as a plain committed directory from 2026-09-24 to 2026-09-25
(VENDORED.md, since removed — its content is folded in below). Switched back
to a proper submodule on 2026-09-25 once the two concrete problems that broke
it the first time were fixed:
.gitmodulesnow pinsbranch = mainexplicitly. The old submodule had no branch, so "Atualizar submódulo" fell back torefs/remotes/origin/HEAD— a ref a plain server-side clone never creates — and failed withUnable to find refs/remotes/origin/HEAD revision.- The submodule URL is
../platform-tools.git(relative, resolves tohttps://git.andmore.pt/andre/platform-tools.git), nothttp://. The old one usedhttp://, which the origin answers with 523.
The third original reason ("the site is deployed by uploading files, so a
submodule is invisible to it") doesn't apply to fitme's actual deploy method —
deploy.sh does git pull --ff-only — so it no longer justifies staying
vendored once the other two are fixed. deploy.sh now runs
git submodule update --init --recursive after the pull, matching every other
config/-based platform in the fleet (fotografia, dsa, moremio, tickets).
Before converting back (2026-09-25): verified the vendored copy was
byte-identical to upstream platform-tools@12f26fd (the SHA it was frozen at)
— only difference was CRLF→LF normalization in four social/ files, already
noted in the old VENDORED.md. Nothing site-specific was hand-patched into
the vendored copy, so nothing was lost by re-pointing at the submodule pinned
to that same commit.
To bump the submodule to a newer platform-tools commit: git submodule update --remote shared/platform-tools && git add shared/platform-tools && git commit
(see the platform-tools README, "Wiring up a platform", step 6) — same as
fotografia.
Deploy-on-push
master now deploys itself: Gitea webhook id 6 on fitme3070.pt (push, branch
master) POSTs to api/platform.php?endpoint=auto_update (the router — no
per-file api/auto_update.php stub needed, since the router's default target
for that endpoint already resolves to the same
shared/platform-tools/api/auto_update.php a stub would have required).
AUTO_UPDATE_SECRET is in .env on the VPS (not in git — see
CLAUDE_GITEA/.auto-update-secrets on Andre's machine), and
system_settings.auto_update_enabled = '1'. Toggle it off from Sistema →
Atualizar plataforma if a push needs to land without auto-deploying.
Why the checkout stays group-writable (664/2775, deploy:www-data): the
webhook's git pull runs inside the PHP request, as www-data, not as
deploy. Tried tightening to 644/2755 on 2026-09-25 (audit 2.6) and the very
next push failed with "Permission denied" creating a new file — reverted
within minutes. config/cache/ and assets/img/seo/ (the app's only two
runtime-write targets inside the checkout besides uploads//logs//
backups/, which already had their own volumes) got their own bind mounts
from /srv/data/fitme.andmore.pt/ in compose.yml, same pattern fotografia
uses — but the checkout itself can't go read-only for www-data without
giving up deploy-on-push.