Observed during #90 release-readiness rerun on 2026-02-28.
Problem:
- `infra/staging/deploy_staging.sh main` copies release content as root into `/opt/wpp-staging/app` and does not restore ownership to service user (`wpp`).
- Staging env uses sqlite path under app dir (`/opt/wpp-staging/app/db.sqlite3`).
- Result: deploy/migrate or service startup can fail with `django.db.utils.OperationalError: unable to open database file`.
Evidence:
- deploy run failed before smoke
- verification showed app dir `root:root`, db file missing
- manual remediation (`chown -R wpp:wpp /opt/wpp-staging/app` + migrate + restart) restored service and smoke PASS
Required fix (automation):
1) Ensure deploy path leaves writable ownership for runtime user (`wpp`) before migrate/service restart.
2) Keep deploy idempotent for future release train runs.
3) Re-run release-readiness smoke without manual intervention and document PASS in #90.
Related: #90, #130
Implemented fix on branch feature/fix-138-staging-app-ownership and opened PR #139.
Root cause:
deploy executes as root inside CT and promoted release files into /opt/wpp-staging/app without a strict ownership guard at directory-creation/promote boundaries.
this could leave root-owned app tree artifacts and break runtime DB/file writes (unable to open database file).
Artifact:
head SHA: 30c22d2f0ce21a9c8e5f030faff979d57a8f9434
commit: 30c22d2 (fix(staging): enforce writable app ownership during deploy)
Implemented fix on branch `feature/fix-138-staging-app-ownership` and opened PR #139.
Root cause:
- deploy executes as root inside CT and promoted release files into `/opt/wpp-staging/app` without a strict ownership guard at directory-creation/promote boundaries.
- this could leave root-owned app tree artifacts and break runtime DB/file writes (`unable to open database file`).
Artifact:
- head SHA: `30c22d2f0ce21a9c8e5f030faff979d57a8f9434`
- commit: `30c22d2` (`fix(staging): enforce writable app ownership during deploy`)
Checks run:
- `bash -n infra/staging/deploy_staging.sh`
PR:
- https://gitea.weircon.dk/wpp/weirsoe-party-protocol/pulls/139
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Observed during #90 release-readiness rerun on 2026-02-28.
Problem:
infra/staging/deploy_staging.sh maincopies release content as root into/opt/wpp-staging/appand does not restore ownership to service user (wpp)./opt/wpp-staging/app/db.sqlite3).django.db.utils.OperationalError: unable to open database file.Evidence:
root:root, db file missingchown -R wpp:wpp /opt/wpp-staging/app+ migrate + restart) restored service and smoke PASSRequired fix (automation):
wpp) before migrate/service restart.Related: #90, #130
Implemented fix on branch
feature/fix-138-staging-app-ownershipand opened PR #139.Root cause:
/opt/wpp-staging/appwithout a strict ownership guard at directory-creation/promote boundaries.unable to open database file).Artifact:
30c22d2f0ce21a9c8e5f030faff979d57a8f943430c22d2(fix(staging): enforce writable app ownership during deploy)Checks run:
bash -n infra/staging/deploy_staging.shPR: