company_site

Django site for AIML Operations.

Local development (uv)

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)

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>.