Prepare GovOPlaN self-hosted release workflow
This commit is contained in:
80
docs/SELF_HOSTED_INSTALLABILITY.md
Normal file
80
docs/SELF_HOSTED_INSTALLABILITY.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Self-Hosted Installability
|
||||
|
||||
GovOPlaN uses a staged self-hosted installability path.
|
||||
|
||||
## Packaging Decision
|
||||
|
||||
The early packaging approach is a staged combination:
|
||||
|
||||
1. Generate an explicit environment template and validate it before startup.
|
||||
2. Use a Compose-backed production-like development profile for local rehearsal.
|
||||
3. Use the deployment operator guide as the runbook for migrations, workers,
|
||||
backups, health checks, and module installer rollback drills.
|
||||
4. Use the module installer CLI/daemon for package mutation once the runtime is
|
||||
already installed and under maintenance mode.
|
||||
|
||||
This keeps first installation understandable while still preserving the later
|
||||
goal of install/update/uninstall through signed catalogs and the installer
|
||||
daemon. The API server must not run package managers from request handlers.
|
||||
|
||||
## Config Bootstrap
|
||||
|
||||
Generate a self-hosted template:
|
||||
|
||||
```bash
|
||||
cd /mnt/DATA/git/govoplan-core
|
||||
./.venv/bin/python -m govoplan_core.commands.config env-template \
|
||||
--profile self-hosted \
|
||||
--generate-secrets \
|
||||
--output .env.self-hosted
|
||||
```
|
||||
|
||||
Validate the current shell environment:
|
||||
|
||||
```bash
|
||||
set -a
|
||||
. .env.self-hosted
|
||||
set +a
|
||||
./.venv/bin/python -m govoplan_core.commands.config validate --profile self-hosted
|
||||
```
|
||||
|
||||
The command reports all known blockers at once. Production-like/self-hosted
|
||||
profiles require explicit `APP_ENV`, `DATABASE_URL`, `MASTER_KEY_B64`,
|
||||
`ENABLED_MODULES`, and `CORS_ORIGINS`. Production rejects SQLite, development
|
||||
bootstrap, insecure auth cookies, and unsigned catalog trust roots when a
|
||||
catalog source is configured.
|
||||
|
||||
## Production-Like Dev Stack
|
||||
|
||||
Use the local production-like wrapper for repeatable rehearsal:
|
||||
|
||||
```bash
|
||||
cd /mnt/DATA/git/govoplan-core
|
||||
scripts/production-like-dev.sh validate-config
|
||||
scripts/production-like-dev.sh seed
|
||||
scripts/production-like-dev.sh start
|
||||
```
|
||||
|
||||
Stop Docker dependencies:
|
||||
|
||||
```bash
|
||||
scripts/production-like-dev.sh stop
|
||||
```
|
||||
|
||||
Reset all profile data:
|
||||
|
||||
```bash
|
||||
scripts/production-like-dev.sh reset --yes
|
||||
```
|
||||
|
||||
The start command delegates to `scripts/launch-production-like-dev.sh`, which
|
||||
runs API, worker, and WebUI in the foreground. Stop those processes with
|
||||
`Ctrl+C` in the launcher terminal.
|
||||
|
||||
## Module Boundary Gate
|
||||
|
||||
`scripts/check_dependency_boundaries.py` is part of the focused verification
|
||||
path. It checks backend imports and WebUI package/source imports so modules do
|
||||
not grow hidden runtime dependencies on each other. Feature modules should
|
||||
integrate through core capabilities, backend APIs/events, route contributions,
|
||||
or explicit UI extension points.
|
||||
Reference in New Issue
Block a user