2026-09-08 13:03:32 +02:00
|
|
|
|
# Delivery checks
|
|
|
|
|
|
|
|
|
|
|
|
Before implementing a workplan, use the hosted reuse registry:
|
|
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
|
make plan-check WORKPLAN=workplans/VERGABE-WP-0018-customer-factory-delivery.md
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
Install a reuse-surface revision containing REUSE-WP-0022. The initially tested
|
|
|
|
|
|
provider revision is recorded in
|
|
|
|
|
|
[evidence/2026-09-08-hosted-plan-check.json](evidence/2026-09-08-hosted-plan-check.json).
|
|
|
|
|
|
`REUSE_SURFACE_BIN` can select an explicit installed executable;
|
|
|
|
|
|
`REUSE_SURFACE_URL` defaults to `https://reuse.coulomb.social`.
|
|
|
|
|
|
|
|
|
|
|
|
This reads current hosted capabilities with `--no-llm`. It sends no tender intent
|
|
|
|
|
|
or mutation token to the registry. A failed/stale/partial source exits nonzero
|
|
|
|
|
|
without a recommendation. Preserve JSON output with the source revision in the
|
|
|
|
|
|
workplan evidence; a lexical `new` result still requires review of existing
|
|
|
|
|
|
capability owners. For this delivery we reuse reuse-surface, Railiance CI tooling
|
|
|
|
|
|
and the existing Railiance Apps deployment rather than establish new equivalents.
|
|
|
|
|
|
|
|
|
|
|
|
## Application and release gate
|
|
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
|
make test-image
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
The `application-tests` Docker target installs the locked Python dependencies,
|
|
|
|
|
|
builds Vite/Tailwind assets, collects static files, runs the complete Django
|
|
|
|
|
|
application suite against disposable SQLite data, and checks migration drift.
|
|
|
|
|
|
It includes the existing tender → lot → approval and submission workflow tests.
|
|
|
|
|
|
The target carries no production database connection or release credential.
|
|
|
|
|
|
SQLite proves this application acceptance suite; target PostgreSQL and live
|
|
|
|
|
|
storage/recovery behavior remain release admission checks.
|
|
|
|
|
|
|
2026-09-08 13:07:22 +02:00
|
|
|
|
The Forgejo application workflow checks proposed changes. The shared
|
|
|
|
|
|
`scripts/ci-docker.sh` installs Docker 27.3.1 and a checksum-pinned Buildx 0.19.3
|
|
|
|
|
|
plugin into temporary per-job state and enables BuildKit. The Railiance runner
|
|
|
|
|
|
otherwise falls back to the legacy builder, which rejects this Dockerfile’s
|
|
|
|
|
|
existing secret mounts. Temporary tool and registry-login state is cleaned at exit.
|
|
|
|
|
|
See [Docker’s BuildKit documentation](https://docs.docker.com/build/buildkit/).
|
|
|
|
|
|
|
|
|
|
|
|
The workflow runs once per PR update; it does not duplicate that run on the
|
|
|
|
|
|
feature-branch push. The image workflow
|
2026-09-08 13:03:32 +02:00
|
|
|
|
runs the same target on the same archive revision **before** registry login and
|
|
|
|
|
|
publication. Test dependencies and test settings are isolated from the runtime
|
|
|
|
|
|
image. The existing optional BuildKit package secrets remain supported, but the
|
|
|
|
|
|
current issue-core package is anonymously readable; no new secret is required.
|
|
|
|
|
|
|
|
|
|
|
|
The corrected Dockerfile consumes application templates under
|
|
|
|
|
|
`vergabe_teilnahme/templates/`. A fresh archive does not contain a root
|
|
|
|
|
|
`templates/` directory; attempting to copy it previously broke clean builds.
|
|
|
|
|
|
|
|
|
|
|
|
## Customer release acceptance
|
|
|
|
|
|
|
|
|
|
|
|
VERGABE-WP-0018-T03 owns the first admitted Railiance customer pilot: exact image
|
|
|
|
|
|
digest and chart revision, tenant/host and login binding, database and media
|
|
|
|
|
|
ownership, backup/restore and rollback, UI smoke and named operating owner.
|
|
|
|
|
|
Existing production tender data is never disposable test data. A passing source
|
|
|
|
|
|
build does not establish customer availability or the governed factory worker.
|
2026-09-11 16:35:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Invited pilot — 2026-09-11
|
|
|
|
|
|
|
|
|
|
|
|
[VERGABE-WP-0019](../workplans/VERGABE-WP-0019-invited-company-pilot.md)
|
|
|
|
|
|
advances one manually onboarded company alongside factory admission. Billing
|
|
|
|
|
|
and a shared tenancy implementation are not pilot gates. All application routes
|
|
|
|
|
|
and media downloads require an active Django account; health and login remain
|
|
|
|
|
|
public. Members can change passwords; administrators create/reset/deactivate
|
|
|
|
|
|
accounts using the existing Django administration through the admitted operator
|
|
|
|
|
|
path. There is no public sign-up or email invitation delivery in this milestone.
|
|
|
|
|
|
|
|
|
|
|
|
Use the Railiance Apps pilot contract in `docs/vergabe-teilnahme-pilot.md` and
|
|
|
|
|
|
RAPPS-WP-0014. Record the newly tested image digest; the older published image
|
|
|
|
|
|
has no global access gate. Persist PostgreSQL, uploads and issue-facade SQLite
|
|
|
|
|
|
separately, and prove coherent restore before admitting customer data. Serve
|
|
|
|
|
|
`/media/` through Django, never directly through an unauthenticated ingress or
|
|
|
|
|
|
static file server. The image's `/app/.issue-facade` directory is operational
|
|
|
|
|
|
state and must never be placed below MEDIA_ROOT.
|
|
|
|
|
|
|
|
|
|
|
|
Application tests use the standard anonymous `client` for access tests and the
|
|
|
|
|
|
explicit `admitted_client` fixture for company workflows. Existing end-to-end
|
|
|
|
|
|
tests retain their explicit login. Container acceptance remains the release
|
|
|
|
|
|
gate; native two-user workflow, restored data, support and rollout evidence
|
|
|
|
|
|
remain open until performed on the admitted deployment.
|
