Files
flyer-crawler.projectium.com/docs/DEV-CONTAINER-BUGSINK.md
Torben Sorensen 38b35f87aa
Some checks failed
Deploy to Test Environment / deploy-to-test (push) Has been cancelled
Bugsink Fixes
2026-01-22 21:48:32 -08:00

101 lines
3.6 KiB
Markdown

# Dev Container Bugsink Setup
Local Bugsink instance for development - NOT connected to production.
## Quick Reference
| Item | Value |
| ------------ | ----------------------------------------------------------- |
| UI | `https://localhost:8443` (nginx proxy from 8000) |
| Credentials | `admin@localhost` / `admin` |
| Projects | Backend (Dev) = Project ID 1, Frontend (Dev) = Project ID 2 |
| Backend DSN | `SENTRY_DSN=http://<key>@localhost:8000/1` |
| Frontend DSN | `VITE_SENTRY_DSN=http://<key>@localhost:8000/2` |
## Configuration Files
| File | Purpose |
| ----------------- | ----------------------------------------------------------------- |
| `compose.dev.yml` | Initial DSNs using `127.0.0.1:8000` (container startup) |
| `.env.local` | **OVERRIDES** compose.dev.yml with `localhost:8000` (app runtime) |
**CRITICAL**: `.env.local` takes precedence over `compose.dev.yml` environment variables.
## Why localhost vs 127.0.0.1?
The `.env.local` file uses `localhost` while `compose.dev.yml` uses `127.0.0.1`. Both work in practice - `localhost` was chosen when `.env.local` was created separately.
## HTTPS Setup
- Self-signed certificates auto-generated with mkcert on container startup
- CSRF Protection: Django configured with `CSRF_TRUSTED_ORIGINS` for both `localhost` and `127.0.0.1` (see below)
- HTTPS proxy: nginx on port 8443 proxies to Bugsink on port 8000
- HTTPS is for UI access only - Sentry SDK uses HTTP directly
### CSRF Configuration
Django 4.0+ requires `CSRF_TRUSTED_ORIGINS` for HTTPS POST requests. The Bugsink configuration (`Dockerfile.dev`) includes:
```python
CSRF_TRUSTED_ORIGINS = [
"https://localhost:8443",
"https://127.0.0.1:8443",
"http://localhost:8000",
"http://127.0.0.1:8000",
]
SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")
```
**Both hostnames are required** because browsers treat `localhost` and `127.0.0.1` as different origins.
If you get "CSRF verification failed" errors, see [BUGSINK-SETUP.md](tools/BUGSINK-SETUP.md#csrf-verification-failed) for troubleshooting.
## Isolation Benefits
- Dev errors stay local, don't pollute production/test dashboards
- No Gitea secrets needed - everything self-contained
- Independent testing of error tracking without affecting metrics
## Accessing Errors
### Via Browser
1. Open `https://localhost:8443`
2. Login with credentials above
3. Navigate to Issues to view captured errors
### Via MCP (bugsink-dev)
Configure in `.claude/mcp.json`:
```json
{
"bugsink-dev": {
"command": "node",
"args": ["d:\\gitea\\bugsink-mcp\\dist\\index.js"],
"env": {
"BUGSINK_URL": "http://localhost:8000",
"BUGSINK_API_TOKEN": "<token-from-local-bugsink>",
"BUGSINK_ORG_SLUG": "sentry"
}
}
}
```
**Get auth token**:
API tokens must be created via Django management command (Bugsink 2.0.11 does not have a "Settings > API Keys" UI):
```bash
podman exec flyer-crawler-dev sh -c 'cd /opt/bugsink/conf && \
DATABASE_URL=postgresql://bugsink:bugsink_dev_password@postgres:5432/bugsink \
SECRET_KEY=dev-bugsink-secret-key-minimum-50-characters-for-security \
DJANGO_SETTINGS_MODULE=bugsink_conf \
PYTHONPATH=/opt/bugsink/conf:/opt/bugsink/lib/python3.10/site-packages \
/opt/bugsink/bin/python -m django create_auth_token'
```
This will output a 40-character lowercase hex token. Copy it to your MCP configuration.
**MCP Tools**: Use `mcp__bugsink-dev__*` tools (not `mcp__bugsink__*` which connects to production).