CI / verify (pull_request) Failing after 47s
CI / infrastructure-smoke (pull_request) Skipped
CI / migration-smoke (pull_request) Skipped
CI / image-build (pull_request) Skipped
CI / deploy-smoke (same-origin) (pull_request) Skipped
CI / deploy-smoke (split) (pull_request) Skipped
The production image now contains zero feature modules and is the same for every installation. Installed modules live in module storage that one Core resolver selects from EKKLESIA_MODULES_DIR: the checkout's modules/ when unset, an absolute path that must exist when set (/var/lib/ekklesia/modules in the image). A relative, blank, missing, or unreadable configured directory fails closed with a sanitized error that never contains the value. - Host configuration reads EKKLESIA_MODULES_DIR. The API, migration plan, apply and validate, module validation, module enablement, and Doctor all resolve it the same way; the test-only API override still takes precedence. - Doctor receives Core's migrations directory explicitly instead of deriving it from the modules directory's parent. - The migration runner retains and reports the applied history of a module that is not installed, and plans and applies Core's and present modules' migrations around it. Core's history and every installed module's history stay strict: a missing or changed applied migration, or a downgrade, still fails. No down migrations, no data deletion. - deploy/Dockerfile copies no module and installs nothing for the module template; .dockerignore excludes modules/ and the build refuses a context that contains it; the runtime has an empty root-owned /var/lib/ekklesia/modules and sets EKKLESIA_MODULES_DIR. - deploy/compose.yaml bind-mounts EKKLESIA_MODULES_HOST_DIR read-only into api and migrate, with create_host_path disabled. - scripts/check-image.sh proves the image holds no modules and that a populated modules/ directory leaves its runtime file system identical; CI runs it. - The split deploy smoke now uses the same generic image: it boots with no modules, installs a self-contained test module packaged from the template (test-only), migrates and restarts, removes it (Core runs, planning reports the retained history, data survives), and restores it with its data. Docs: deploy README (module storage, install/update/remove/restore, the runtime modules target), .env.example, API configuration, module development guide, testing, workflow, security, and the architecture overview. Co-Authored-By: Claude Opus 5.5 <[email protected]>
67 lines
2.7 KiB
TypeScript
67 lines
2.7 KiB
TypeScript
import path from "node:path";
|
|
import {
|
|
isUsableModulesDirectoryPath,
|
|
MODULES_DIRECTORY_INVALID_MESSAGE,
|
|
ModuleDiscoveryError,
|
|
} from "./discovery.js";
|
|
|
|
/** The host environment variable that selects the installed-modules directory (ADR 0048). */
|
|
export const MODULES_DIRECTORY_ENVIRONMENT_VARIABLE = "EKKLESIA_MODULES_DIR";
|
|
|
|
export interface ResolveModulesDirectoryOptions {
|
|
/** The raw configured value, exactly as the host environment supplied it; `undefined` when the
|
|
* variable is unset. */
|
|
readonly configured: string | undefined;
|
|
/** Where the platform itself is installed. Only consulted for the development default. */
|
|
readonly repositoryRoot: string;
|
|
}
|
|
|
|
/** Spreads directly into `ModuleDiscoveryOptions`, so every consumer discovers through the same
|
|
* selection, including whether a missing directory is an error. */
|
|
export interface ModulesDirectorySelection {
|
|
readonly modulesDirectory: string;
|
|
readonly modulesDirectoryRequired: boolean;
|
|
}
|
|
|
|
/**
|
|
* The one place an installation's modules directory is chosen (ADR 0048).
|
|
*
|
|
* - Unset: `<repositoryRoot>/modules`, the development checkout's own directory. A checkout without
|
|
* one has no modules, exactly as before.
|
|
* - Set: an absolute path, normalized and used as given — never resolved against the repository or
|
|
* the working directory — and required to exist when discovery reads it. The shipping image sets
|
|
* it to `/var/lib/ekklesia/modules`.
|
|
*
|
|
* Anything else throws a `ModuleDiscoveryError` carrying `MODULES_DIRECTORY_INVALID` and a fixed
|
|
* message, so every executable already reports it through the discovery error path it has, and the
|
|
* supplied value never reaches an error, a log, or a report.
|
|
*
|
|
* Nothing here — and nothing that calls it — locates the platform's own files relative to the
|
|
* result: Core's migrations and package metadata live under `repositoryRoot`, wherever modules are.
|
|
*/
|
|
export function resolveModulesDirectory(
|
|
options: ResolveModulesDirectoryOptions,
|
|
): ModulesDirectorySelection {
|
|
if (options.configured === undefined) {
|
|
return Object.freeze({
|
|
modulesDirectory: path.join(options.repositoryRoot, "modules"),
|
|
modulesDirectoryRequired: false,
|
|
});
|
|
}
|
|
if (!isUsableModulesDirectoryPath(options.configured)) {
|
|
throw new ModuleDiscoveryError([
|
|
{
|
|
code: "MODULES_DIRECTORY_INVALID",
|
|
message: MODULES_DIRECTORY_INVALID_MESSAGE,
|
|
moduleDirectory: ".",
|
|
},
|
|
]);
|
|
}
|
|
const normalized = path.normalize(options.configured);
|
|
return Object.freeze({
|
|
modulesDirectory:
|
|
normalized.length > 1 && normalized.endsWith(path.sep) ? normalized.slice(0, -1) : normalized,
|
|
modulesDirectoryRequired: true,
|
|
});
|
|
}
|