c28e4b2de713c7873ba57e635478939adbe2c802
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 ekklesia
|
c28e4b2de7 | ci: restore external package integration | ||
|
ekklesiaandClaude Opus 5.5
|
33bb146349 |
feat: build Signage on its own from the published Ekklesia 0.2.0 packages
Signage no longer needs an Ekklesia checkout. A clean clone installs with `pnpm install --frozen-lockfile` and runs lint, typecheck, test, build, and validate by itself, taking Ekklesia's module-development packages from Ekklesia's public registry (ADRs 0053 and 0054). - Dependencies: every `workspace:*` becomes `^0.2.0`. @ekklesia/module-pack is added as a devDependency pinned exactly to 0.2.0, as ADR 0053 requires; it is not invoked yet. No @ekklesia/contracts dependency. drizzle-orm stays a direct dependency, satisfying the adapter's optional peer. - .npmrc points the @ekklesia scope at https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/ with no credential, because reading needs none. - pnpm-workspace.yaml holds this repository's pnpm settings only: - `allowBuilds: esbuild: true`, as the platform's standalone fixture does; - exact-version minimumReleaseAgeExclude entries for the 0.2.0 train, which pnpm 11 otherwise holds back on its release day; - the platform's narrowly scoped override for GHSA-67mh-4wv8-2f99 (esbuild via drizzle-kit), which Signage inherited while it built inside Ekklesia's workspace. - engines.node `>=24.11.0 <25` and packageManager `[email protected].0`, both from Ekklesia 0.2.0. Node 24.18.0 goes in .node-version for CI, as in Ekklesia. - biome.json carries the platform's Biome configuration, which `biome lint` used to pick up from the workspace root, so lint rules are unchanged. - pnpm-lock.yaml is Signage's own: registry tarballs with integrity hashes, and no workspace or file links. - `prepack` runs this package's own build instead of the workspace root's turbo. - `pnpm validate` (scripts/validate-module.mjs) checks the built package and its migrations with the published SDK parsers only: - the manifest, its identity, and its entrypoints; - that the built runtime's id, version, and database ABI match the manifest; - that the built schema metadata is plain, namespaced, and has module-internal foreign keys; - the SDK compatibility range; - that the migration journal and policy agree. Core's own `modules:validate` and `migrations:validate` are not published. What only an Ekklesia installation can check is named in the script. Removed: ci/assemble.sh, ci/platform.env, ci/pnpm-lock.yaml, ci/update-lock.sh. The lint, typecheck, test, and build jobs check out only this repository; build also runs `pnpm validate`. The integration job stays disabled. Its first step is now an explicit placeholder rather than the deleted assembly, and its explanation says it returns when Signage is a canonical linux-x64-glibc Module Package installed into Ekklesia's generic image. No source, behaviour, schema, or version change: Signage stays 0.1.2. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5.5
|
a6d553efbb |
feat: move Signage to the Ekklesia 0.2 module contract (manifest v8, database ABI v1)
Signage moves from the legacy module contract to Ekklesia 0.2.0's, with no behaviour or schema
change:
- manifest version 8, `database: { abi: 1 }`, compatibility ^0.2.0 for platform and module SDK;
the runtime declares the same ABI, as Core requires;
- every store reaches PostgreSQL through the platform's Module Database ABI v1 executor, with
Signage's own Drizzle tables and the module-side adapter (`moduleDrizzle`) from
@ekklesia/module-database. createSignageStore takes the executor, so no call site changes;
- the schema entrypoint exports only plain ABI v1 metadata (table names and foreign-key targets),
derived from tables.ts with moduleDrizzleSchemaMetadata; no Drizzle object reaches Core;
- duplicate-image detection reads SQLSTATE 23505 from the stable Ekklesia database error, found
with findEkklesiaDatabaseError through Drizzle's DrizzleQueryError wrapping. The old
`error.code === "23505"` check never matched a wrapped error, so a duplicate-upload race
surfaced as a 500 instead of the content-hash conflict.
tables.ts declarations, the migration, and its pinned checksum are unchanged.
Tests: an ABI v1 executor double that enforces Core's scope, parameter, and abort rules drives all
13 store transactions, their rollbacks, raw int8/timestamptz/jsonb decoding, and the 23505
regression, including generic and driver-shaped errors that must not count as duplicates.
CI, temporarily: the platform pin moves to v0.2.0 (1788d17) with a regenerated ci/pnpm-lock.yaml.
The integration job is disabled: from 0.2.0 the platform image is generic (ADR 0048) and installs
modules only as Module Packages, which Signage cannot be until its sharp dependency goes through
the native package flow. The job and ci/integration.sh stay, and the job returns in that change.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
|
||
|
ekklesiaandClaude Opus 5.5
|
cbf2a8ee39 |
ci: the integration job removes its stacks even when the runner kills it
The platform's rule (its ci-sweep.sh, docs/development/security.md), applied to the one Signage job that starts Docker stacks: - it has its own EKKLESIA_CI_JOB_KEY; - it sweeps stale CI stacks from the runner before it starts; - it removes its own stacks in a final `if: always()` step, which tolerates a failed assembly, since nothing was started then; - the image ci/integration.sh builds is named and labeled as a CI stack of this run and job, with the time CI built it, so the sweep finds it. ci/platform.env moves to the platform commit that adds the sweep (Ekklesia #60). The assembled lockfile is unchanged, and still passes a frozen install. Verified: SIGKILL of the integration script's whole process group mid-run left 11 resources (2 containers, 4 networks, 4 volumes and the image). `ci-sweep.sh --job` removed exactly those 11. A normal run passes, and the job sweep after it finds nothing. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5.5
|
cfa4628f8c |
test(ci): the integration job must clean up its stacks even when killed
The platform leaked a whole CI stack for two days: a job the runner kills never runs its cleanup trap. The platform's rule now applies here: the job that starts Docker stacks (integration) has its own EKKLESIA_CI_JOB_KEY, sweeps stale CI stacks first, removes its own in a final if: always() step, and labels the image it builds. ci/check-cleanup.sh checks that, and the lint job runs it. It fails today on all five counts. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
|
ekklesiaandClaude Opus 5.5
|
3073baeb8b |
ci: build, test, and run Signage inside a pinned Ekklesia on every change
Signage had no CI. Its tests passed while three defects shipped that appear only inside Ekklesia, in a real browser. Every job now assembles Signage into a pinned platform commit, as an instance does, and installs that workspace with --frozen-lockfile: - lint, typecheck, test: Signage's own checks; - build: the platform's gates against exactly this module set (boundary rules, module manifest, migrations), then the build; - integration: the deployment image from the platform's Dockerfile, then the platform's split-topology smoke. It pairs a kiosk display, restarts it on the same profile, and runs the scenarios in ci/display-scenarios. The supporting files: - ci/platform.env pins one platform commit. ci/assemble.sh fetches the platform's main and refuses a pinned commit that is not on it, so CI only runs reviewed platform code. - ci/pnpm-lock.yaml is the assembled workspace's lockfile, regenerated with ci/update-lock.sh. Same trust rules as the platform: actions pinned by SHA, persist-credentials false, no secrets, no pull_request_target. Co-Authored-By: Claude Opus 5.5 <[email protected]> |