Ship an example settings policy, and name the variables in .env.example
#231 added the policy but nothing to copy. The repo already answers this the same way four times over -- Caddyfile.example, deploy.example.sh, nginx.example.conf, .env.example -- and the new feature was the one thing configurable here with no example beside it. settings-policy.example.json carries all three sections with the reasoning in it, including the part worth being deliberate about: a `changes` entry overrides a decision a reader has already made, and if you want it to stay put regardless that is `enforced` instead. JSON has no comments, so the commentary is in `_`-prefixed keys, which is safe because the server reads three names and ignores everything else. A test asserts the shipped example stays valid against the rules the parser enforces -- unique versions, settings objects, no comment key colliding with a real section. An example that has drifted is worse than none: somebody copies it, the server refuses to start, and the first experience of the feature is a crash loop. .env.example gains the four variables, commented out, with the file form and the inline form and the note that the file wins over the variables. Confirmed against the real image on the deploy host rather than reasoned about: an immutable container -- --read-only, IMMUTABLE=1, SESSION_FILE= empty -- starts and serves the policy both with a read-only file mount and with the environment variables alone. The feature costs nothing in immutability, because the only thing it writes is the applied-changes stamp, and that goes in the reader's own settings file on Stalwart like every other setting.
This commit is contained in:
@@ -0,0 +1,55 @@
|
||||
import { test } from "node:test";
|
||||
import assert from "node:assert/strict";
|
||||
import { readFileSync } from "node:fs";
|
||||
import { fileURLToPath } from "node:url";
|
||||
|
||||
/**
|
||||
* The shipped example policy, checked against the rules the server enforces.
|
||||
*
|
||||
* An example that has drifted out of step with the parser is worse than no
|
||||
* example: somebody copies it, the server refuses to start, and the first
|
||||
* experience of the feature is a crash loop. This does not import the config
|
||||
* module -- reading it has side effects and wants a whole environment -- so the
|
||||
* rules it checks are restated here, and both are short enough that saying them
|
||||
* twice is cheaper than the machinery to say them once.
|
||||
*/
|
||||
const EXAMPLE = fileURLToPath(new URL("../../settings-policy.example.json", import.meta.url));
|
||||
|
||||
test("the example policy is valid JSON", () => {
|
||||
assert.doesNotThrow(() => JSON.parse(readFileSync(EXAMPLE, "utf8")));
|
||||
});
|
||||
|
||||
test("the example policy has the three sections, in the shapes the server reads", () => {
|
||||
const p = JSON.parse(readFileSync(EXAMPLE, "utf8")) as Record<string, unknown>;
|
||||
for (const section of ["defaults", "enforced"]) {
|
||||
const v = p[section];
|
||||
assert.ok(v && typeof v === "object" && !Array.isArray(v), `${section} must be an object`);
|
||||
}
|
||||
assert.ok(Array.isArray(p.changes), "changes must be a list");
|
||||
});
|
||||
|
||||
test("every change in the example has a unique version and settings", () => {
|
||||
const p = JSON.parse(readFileSync(EXAMPLE, "utf8")) as { changes: Array<{ version?: unknown; settings?: unknown }> };
|
||||
const seen = new Set<string>();
|
||||
for (const [i, c] of p.changes.entries()) {
|
||||
assert.equal(typeof c.version, "string", `changes[${i}] needs a string version`);
|
||||
assert.ok((c.version as string).trim(), `changes[${i}] needs a non-empty version`);
|
||||
assert.ok(!seen.has(c.version as string), `changes[${i}] repeats version ${String(c.version)}`);
|
||||
seen.add(c.version as string);
|
||||
assert.ok(c.settings && typeof c.settings === "object" && !Array.isArray(c.settings), `changes[${i}] needs a settings object`);
|
||||
}
|
||||
});
|
||||
|
||||
test("the example's commentary cannot be mistaken for a section", () => {
|
||||
/*
|
||||
* JSON has no comments, so the example explains itself in `_`-prefixed keys.
|
||||
* The server reads three names and ignores everything else, which is what
|
||||
* makes that safe -- but only for as long as no comment key collides with a
|
||||
* real one.
|
||||
*/
|
||||
const p = JSON.parse(readFileSync(EXAMPLE, "utf8")) as Record<string, unknown>;
|
||||
const real = new Set(["defaults", "enforced", "changes"]);
|
||||
for (const key of Object.keys(p)) {
|
||||
assert.ok(real.has(key) || key.startsWith("_"), `unexpected top-level key ${key}`);
|
||||
}
|
||||
});
|
||||
Reference in New Issue
Block a user