The v* tag deploy previously only updated the Next app (ppms); GstService /
EpfoService / PdfService were never built or restarted by automation. Now the
same deploy manages them.
- ecosystem.config.js (root): pm2 definitions for gst-service (3003) /
epfo-service (3004) / pdf-service (3005). Registers only services whose source
is checked out (keyed on package.json), so a not-yet-merged service is skipped
and adopted automatically once its PR lands. Secrets come from the env at pm2
invocation; ports are fixed here.
- deploy.yml: after the app restart, export the few service secrets out of
App/.env (never PORT or the ephemeral FORGEJO_TOKEN), npm install + playwright
install chromium + build each present service, then
`pm2 startOrReload ecosystem.config.js --update-env` (create on first release,
reload after) + pm2 save, and health-check :3003/:3004/:3005.
- automation/README.md: documents the flow + the one-time alignment for any
pre-existing differently-named pm2 process.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The deploy job runs inside the Forgejo Actions runner, whose env includes an
ephemeral FORGEJO_TOKEN (per-job token, revoked when the job ends). 'pm2 restart
--update-env' injected it into ppms, where it shadowed the real PAT in .env
(Next.js won't override an already-set process.env var) — so the Report Issue
button 401'd once the job token expired. Plain restart keeps the daemon's clean env.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Report Issue button in portal header files a Forgejo issue (portal + claude-queue labels)
- Windows scheduled watcher runs headless Claude Code on queued issues and opens a PR
- .forgejo/workflows/deploy.yml deploys v* release tags via the pms1 host runner (pm2 restart ppms)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
