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>
57 lines
3.2 KiB
Markdown
57 lines
3.2 KiB
Markdown
# 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:
|
|
|
|
- `.gitmodules` now pins `branch = main` explicitly. The old submodule had no
|
|
branch, so "Atualizar submódulo" fell back to `refs/remotes/origin/HEAD` — a
|
|
ref a plain server-side clone never creates — and failed with
|
|
`Unable to find refs/remotes/origin/HEAD revision`.
|
|
- The submodule URL is `../platform-tools.git` (relative, resolves to
|
|
`https://git.andmore.pt/andre/platform-tools.git`), not `http://`. The old
|
|
one used `http://`, 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.
|