# company_site

Django site for AIML Operations.

## Local development (uv)

```bash
uv sync
cp .env.example .env
cd company_site
DJANGO_ENV=dev uv run python manage.py migrate
DJANGO_ENV=dev uv run python manage.py runserver
```

## Docker (dev + Postgres)

```bash
cp .env.example .env
docker compose up --build
```

App: http://localhost:8000

## Environments

Set `DJANGO_ENV` to one of:

| Value | DEBUG default | Logging level |
|-------|---------------|---------------|
| `dev` | true | DEBUG |
| `beta` | false | INFO |
| `prod` | false | WARNING |

Secrets and service config come from environment variables. See `.env.example`.

## CI / deploy workflows

| Workflow | Trigger | What runs |
|----------|---------|-----------|
| `.gitea/workflows/ci.yml` | Pull requests to `master` | Unit tests only |
| `.gitea/workflows/deploy.yml` | Push to `master` | Unit tests → Docker build/test → deploy |

Deploy never runs on pull requests. Uses separate workflow files (not job `if` conditions) so Gitea runners handle it reliably.

## Production deploy

Server keeps its own `.env` at the live site path. Deploy rsyncs code but **never overwrites `.env`**.

1. On the server, copy `.env.prod.example` to `.env` and fill in production values.
2. Run `bash scripts/validate-env.sh /path/to/.env` to verify required variables.
3. Push to `master` — the deploy workflow runs `scripts/deploy.sh`, which:
   - rsyncs checkout to live site (preserving `.env`)
   - validates environment variables
   - `docker compose -f docker-compose.prod.yml build`
   - `docker compose up -d`
   - runs migrations in the web container

Legacy venv/systemd deploy: `DEPLOY_MODE=legacy bash scripts/deploy.sh <checkout>`.