Address issue #20 and the CI divergence between Gitea and GitHub.
Issue #20 (staging seeded from a prod snapshot):
- Read SECRET_KEY from the environment with the insecure dev key as
fallback, so each deployment can have its own key.
- Add a `scrub_staging` management command that clears django_session and
the django-q schedule/queue/results, removing copied prod sessions and
the inherited convert_prices() schedule.
- Run the scrub from entrypoint.sh when STAGING=true, and wire STAGING plus
a per-branch SECRET_KEY into the Gitea staging deploy.
CI parity (both systems kept, independent):
- Add the Node/pnpm/TypeScript build steps to the Gitea build workflow to
match the GitHub test job.
- Add a GitHub staging workflow that deploys per-branch ephemeral instances
to Fly.io (*.fly.dev) with a fresh database seeded from sample fixtures
and its own SECRET_KEY, never production data. Tears the app down on
branch delete and comments the URL on the open PR via github-script.
- Add fly.staging.toml and a LOAD_SAMPLE_DATA entrypoint hook for the
fresh-database public staging.
https://claude.ai/code/session_01KYjUcNjLfZ8Hq1GAC8J4oZ
Claude
lukas
