yrtria/theme-song-booth
Archived
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

feat: add ntfy push notifications for new requests

Browse source 
- Add ntfy server/topic settings in /admin/settings next to Hermes API key
- POST a push notification to the configured topic on every new customer request
- Add a Send Test ntfy button to verify configuration
- Add requests dependency for ntfy HTTP calls
- Bump version to 0.5.6
This commit is contained in:
Troll (Hermes Agent) 2026-08-07 17:14:02 +00:00
parent 410a9cf021
commit a56f6e498b
6 changed files with 105 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

12
REVIEW.md
View file

@ -11,7 +11,7 @@ Flask app that lets convention attendees request custom AI-generated theme songs
- Python 3.12 + Flask
- SQLite (file-based, request-scoped connection via `g`)
- Gunicorn in Docker
- Portainer stack deployed from GitLab repo
- Portainer stack deployed from Gitea repo
- SMTP (SSL port 465) for customer emails
- Square Terminal/Reader for manual payment
- `mutagen` for MP3 metadata tagging
@ -20,7 +20,7 @@ Flask app that lets convention attendees request custom AI-generated theme songs
## Repository
- GitLab: `https://gitlab.hallsworth.ca/yrtria/theme-song-booth` (public)
- Gitea: `https://gitlab.hallsworth.ca/yrtria/theme-song-booth` (public)
- Deployed at: `https://booth.dionysismedia.ca`
## Key files and what they hold
@ -112,7 +112,7 @@ These survive redeploys because `booth_settings.json` lives in the persistent up
## How to redeploy
1. Push changes to GitLab `main`.
1. Push changes to Gitea `main`.
2. In Portainer: Stacks → `theme-song-booth` → **Pull and redeploy**.
3. If schema changed, open container console and run `python init_db.py`, or use `/admin/settings` → **Fix Database Schema**.
@ -134,17 +134,17 @@ These survive redeploys because `booth_settings.json` lives in the persistent up
## Project state notes
- No `.gitlab-ci.yml` is currently in the repo; old pipeline records from an earlier CI config are still visible in GitLab but are not actionable because no runners are attached. Add a CI skeleton (see below) if you want automated checks back.
- No `.gitlab-ci.yml` is currently in the repo; old pipeline records from an earlier CI config are still visible in Gitea but are not actionable because no runners are attached. Add a CI skeleton (see below) if you want automated checks back.
- No automated tests exist yet.
## CI skeleton (optional)
A **CI skeleton** is the smallest GitLab CI config that gives you useful automated checks on every push without needing a heavy test suite. For this project it would be a `.gitlab-ci.yml` with one or two jobs:
A **CI skeleton** is the smallest Gitea CI config that gives you useful automated checks on every push without needing a heavy test suite. For this project it would be a `.gitlab-ci.yml` with one or two jobs:
1. **Syntax check job** — install Python dependencies and run `python -m py_compile app.py models.py config.py init_db.py` to catch SyntaxErrors before they reach Portainer.
2. **(Optional) Test job** — run a minimal pytest suite once tests are written. Right now this would be a placeholder that skips if no tests exist, so the pipeline stays green while you decide whether to add tests.
It needs a GitLab runner to execute. Your GitLab instance has no runners attached, which is why the old pipelines are stuck/canceled. The skeleton just defines *what* to run; a runner is still required for it to actually execute.
It needs a Gitea runner to execute. Your Gitea instance has no runners attached, which is why the old pipelines are stuck/canceled. The skeleton just defines *what* to run; a runner is still required for it to actually execute.
## Static assets to keep in the repo