The deploy.yml workflow_dispatch input always defaulted to 'v0.1.0',
requiring manual edit every time. Now the version defaults to 'auto',
which fetches all tags, finds the latest v* tag via semver sort, bumps
the patch component, and uses that as the deploy tag.
Changes:
- deploy.yml input: default changed to 'auto', required → false,
description updated to explain both auto and manual modes
- Added 'Resolve version' step: fetches tags, bumps latest semver
tag by patch, validates output format, exports to $VERSION
- 'Tag version' step: substituted ${{ github.event.inputs.version }}
→ ${{ env.VERSION }} to use the resolved/computed version
- 'Print deploy status' step: same substitution
- Semver validation guard rejects malformed tags (auto and manual)
Enable pageview tracking when VITE_UMAMI_WEBSITE_ID is set at frontend
build time (Forgejo secret + deploy workflow), with SPA route updates
and no script in local dev. Document setup in docs/umami-analytics.md,
extend integritetspolicy, and add admin Webbstatistik link in prod builds.
Co-authored-by: Cursor <cursoragent@cursor.com>
Forgejo workflow_dispatch requires an explicit input type; without it the
UI showed invalidinputtype. Clarify README: workflow ref vs version tag.
Co-authored-by: Cursor <cursoragent@cursor.com>
Deploy workflow now writes MAIL_* and APP_PUBLIC_BASE_URL from Actions
secrets into the server .env so Resend SMTP works after domain verify.
Document Resend-only setup, Forgejo secret names, and prod expose-token off.
Co-authored-by: Cursor <cursoragent@cursor.com>
Production deploy failed with no backend logs before rollback. Print
backend and postgres logs on failure, wait longer for JVM startup, and
probe /api/payment/swish-info instead of vehicle lookup (no external scrape).
- Document proof-first troubleshooting in README
- No volume reset workflow; fix only after reading job logs
Docker Compose interpolates $VAR in .env files. Passwords like ...$A72y...
were truncated and the backend failed health checks, triggering rollback.
- Escape $ as $$ when writing production secrets to .env
- Document that deploy handles literal $ in Forgejo secrets
Production must not ship test users, demo orders, or test1234. Dev and CI
still need seeded users for e2e. Prod creates one admin from deploy secrets.
- Move V2/V4/V6 seed migrations to db/dev-migration
- Add application-prod.yml with schema-only Flyway and ignore-missing for moved seeds
- Add AdminBootstrap to create admin from ADMIN_EMAIL and ADMIN_PASSWORD
- Wire docker,prod profile, deploy secrets, and localhost:5433 for SSH DB access
- Add hashPassword Gradle task for optional manual bcrypt generation
The deploy pipeline had two critical bugs:
1. Health check used /api/vehicles/ZZZ999 with curl -f. This endpoint
returns HTTP 404 for unknown plates (correct behavior), which curl -f
treated as a failure. The backend was actually healthy.
Fix: use /api/vehicles/ABC123 (seeded in V6 migration, always 200)
and remove -f flag from curl.
2. No rollback on failure. If health checks failed, containers stayed
running forever because the pipeline exited 1 without stopping them.
Fix: combine health checks into one step. If either fails, run
'docker compose down' (without -v, so DB volume is preserved) before
exiting with failure.
The production deploy failed because port 3000 was already bound by the
dev frontend container (bilhej-frontend). The prod frontend doesn't need
a host port at all — nginx talks to it via the external 'web' network.
Changes:
- Remove host port binding (3000:80) from prod frontend
- Remove unused 'certs' volume from prod compose
- Use --project-name bilhej-prod in deploy workflow to isolate prod
containers/networks from dev and e2e environments
- Add 'docker compose down' before 'up' for clean deploys
- Update health check network names to bilhej-prod_default
The deploy workflow failed when re-running with the same version tag
because Git rejects pushing a tag that already exists on the remote.
- Delete local tag first (ignore if missing)
- Delete remote tag first (ignore if missing)
- Create and push the tag fresh
This makes deploys idempotent: retrying a failed deploy with the same
version (e.g., v0.1.0) will succeed by moving the tag to the current
commit. For a new deploy, the delete commands silently do nothing.
Add a manually-triggered deploy workflow that builds production Docker
images and starts the stack on the srvr.nu server.
- : workflow_dispatch with version input,
writes production .env from Forgejo secrets, builds and starts the
docker-compose.prod.yml stack, runs health checks via temporary curl
containers on the bilhej_default Docker network, tags the git commit.
- : nginx server block for bilhej.se.
Handles HTTP→HTTPS redirect, SSL termination with Let's Encrypt certs,
and proxies all traffic to the bilhej-frontend-prod container on the
Docker 'web' network. The frontend container handles /api/ proxying
to the backend internally.
To deploy:
1. Add production secrets to Forgejo (Settings → Actions → Secrets)
2. Trigger deploy from Actions → Deploy to Production
3. Run certbot for bilhej.se SSL (one-time setup)
4. Add docker/bilhej.nginx.conf to srvr.nu nginx container
5. Point bilhej.se DNS A record to srvr.nu IP
