feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
import { describe, expect, it, vi } from "vitest";
|
feat: diff and apply a database's backup schedule (#51)
Backup schedules were write-only, filed under "known limitations" on the
claim that "live Coolify state doesn't expose it back". The parenthesis was
load-bearing and false: a schedule is not on the database's own GET, but it
was never meant to be — it has its own route, GET /databases/{uuid}/backups,
which cast had been POSTing to all along and had simply never read.
The cost was exact. A database created before its `backup:` block was
declared never got one (apply set the schedule only inside the create
branch); a schedule deleted in the UI was invisible; and the `--full` diff
that gates a production cutover passed with an unbacked-up production
database.
Shape settled from the source rather than the vendored spec, which documents
the body as "Content is very complex. Will be implemented later.":
DatabasesController@database_backup_details_uuid (v4.1.2) returns a raw
Eloquent collection — a JSON array of ScheduledDatabaseBackup rows, columns
per $fillable (uuid, enabled, frequency,
database_backup_retention_amount_locally). `frequency` round-trips verbatim:
the controller validates it and stores $request->only(...) unchanged, with no
mutator on the model. The "diffing it would flag spurious drift" fear was a
guess about a read nobody had performed.
- `backup` becomes a diffed field like any other (resolve.ts), replacing the
side channel that carried it around the diff.
- The live side reads the route (coolify.ts, fetchLive), and apply sets the
schedule on UPDATE as well as create — POST or PATCH, decided by a read.
- A disabled schedule is a row that backs nothing up: neither clean nor
absent. cast diffs it and re-enables it.
Degrades honestly, since no live box was probed: an unreachable or
unrecognized response can only ever produce "declared, NOT compared — verify
in the Coolify UI", never invented drift and never a clean bill on an
unread database. On the write side the same failure raises rather than
guessing — POSTing blind would duplicate a schedule that may already exist.
2026-07-14 22:37:01 +00:00
|
|
|
import { CoolifyClient, parseBackupSchedules } from "../src/coolify.js";
|
|
|
|
|
|
|
|
|
|
// A row as Coolify actually serializes one: a raw ScheduledDatabaseBackup
|
|
|
|
|
// Eloquent model (DatabasesController@database_backup_details_uuid, v4.1.2),
|
|
|
|
|
// so every column is present and `executions` is eager-loaded alongside.
|
|
|
|
|
const row = (over: Record<string, unknown> = {}) => ({
|
|
|
|
|
id: 3,
|
|
|
|
|
uuid: "sched-1",
|
|
|
|
|
team_id: 1,
|
|
|
|
|
enabled: true,
|
|
|
|
|
save_s3: true,
|
|
|
|
|
frequency: "0 3 * * *",
|
|
|
|
|
database_backup_retention_amount_locally: 7,
|
|
|
|
|
database_id: 9,
|
|
|
|
|
database_type: "App\\Models\\StandalonePostgresql",
|
|
|
|
|
s3_storage_id: 2,
|
|
|
|
|
executions: [],
|
|
|
|
|
...over,
|
|
|
|
|
});
|
feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
|
|
|
|
|
function mockFetch(routes: Record<string, unknown>) {
|
|
|
|
|
return vi.fn(async (url: string | URL, init?: RequestInit) => {
|
|
|
|
|
const key = `${init?.method ?? "GET"} ${new URL(String(url)).pathname}`;
|
|
|
|
|
if (!(key in routes)) return new Response("not found", { status: 404 });
|
|
|
|
|
return new Response(JSON.stringify(routes[key]), { status: 200 });
|
|
|
|
|
}) as unknown as typeof fetch;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
describe("CoolifyClient", () => {
|
|
|
|
|
it("sends bearer auth and resolves servers by name", async () => {
|
|
|
|
|
const fetchImpl = mockFetch({
|
|
|
|
|
"GET /api/v1/servers": [{ uuid: "srv-1", name: "prod-box" }],
|
|
|
|
|
});
|
|
|
|
|
const c = new CoolifyClient("https://coolify.test", "tok", fetchImpl);
|
|
|
|
|
expect(await c.serverUuid("prod-box")).toBe("srv-1");
|
|
|
|
|
const call = (fetchImpl as unknown as ReturnType<typeof vi.fn>).mock
|
|
|
|
|
.calls[0];
|
|
|
|
|
expect((call[1].headers as Record<string, string>).Authorization).toBe(
|
|
|
|
|
"Bearer tok",
|
|
|
|
|
);
|
|
|
|
|
});
|
|
|
|
|
it("throws a named error when a resolver misses", async () => {
|
|
|
|
|
const c = new CoolifyClient(
|
|
|
|
|
"https://coolify.test",
|
|
|
|
|
"tok",
|
|
|
|
|
mockFetch({ "GET /api/v1/servers": [] }),
|
|
|
|
|
);
|
|
|
|
|
await expect(c.serverUuid("nope")).rejects.toThrow(
|
|
|
|
|
/not found in Coolify: server nope/,
|
|
|
|
|
);
|
|
|
|
|
});
|
|
|
|
|
it("surfaces API errors with method, path and status", async () => {
|
|
|
|
|
const c = new CoolifyClient("https://coolify.test", "tok", mockFetch({}));
|
|
|
|
|
await expect(c.get("/projects")).rejects.toThrow(/GET \/projects → 404/);
|
|
|
|
|
});
|
feat: assert the token's team before touching Coolify (fail-closed)
Coolify API tokens are team-scoped, and a wrong-team token does not error:
the API resolves what it cannot see to `null` (getResourceByUuid walks
resource → environment → project → team_id and returns null on a mismatch).
To cast, `null` is indistinguishable from "this resource does not exist
yet" — an invitation to create it. So an apply with a token minted under the
wrong team would not fail loudly; it would provision a duplicate set of
resources into the wrong team, against whatever server that team owns.
Silent, mutating, discovered late. That makes this a correctness bug, not
hardening.
- environments.yaml carries a required `team:` per environment (id, name, or
both). Required is the point: an environment with no declared team is one
cast cannot verify it is pointed at.
- Every command that reaches a live Coolify (apply, diff, server add, smoke)
resolves GET /teams/current — the only endpoint that answers "what team
does this token act as?" — and aborts on mismatch before its first READ,
not merely its first write: a wrong-team diff reports "everything is
absent", which is the very lie an apply would then act on.
- server add and smoke take --env for this reason. A server belongs to
exactly one team forever (no pivot, no is_system_wide escape hatch), and
smoke writes env vars onto a live app.
- New read-only `cast team` prints the token's team, so the binding can be
filled in without a chicken-and-egg. With --env it also checks the
binding: the dry run for "would apply refuse?".
Team id 0 is a first-class value, not a falsy absent — it is the Root Team
that a single-admin instance keeps everything in (app/Models/User.php).
Also records the #4 investigation in docs/semantics.md: GithubApp
`is_system_wide` IS the supported way to serve every team — list_github_apps
scopes to `team_id = token's team OR is_system_wide`, and POST /github-apps
accepts the flag — so per-team App duplication is unnecessary. Corollary:
resolving a GitHub App by name is NOT a proxy for being in the right team,
which is the second reason the assert has to be explicit.
Closes #9
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-12 20:55:04 +00:00
|
|
|
it("reads the token's team from /teams/current", async () => {
|
|
|
|
|
const c = new CoolifyClient(
|
|
|
|
|
"https://coolify.test",
|
|
|
|
|
"tok",
|
|
|
|
|
mockFetch({
|
|
|
|
|
"GET /api/v1/teams/current": {
|
|
|
|
|
id: 1,
|
|
|
|
|
name: "heavy-duty",
|
|
|
|
|
personal_team: false,
|
|
|
|
|
},
|
|
|
|
|
}),
|
|
|
|
|
);
|
|
|
|
|
await expect(c.currentTeam()).resolves.toEqual({
|
|
|
|
|
id: 1,
|
|
|
|
|
name: "heavy-duty",
|
|
|
|
|
});
|
|
|
|
|
});
|
feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
it("reads version as plain text, not JSON", async () => {
|
|
|
|
|
const fetchImpl = vi.fn(
|
|
|
|
|
async () => new Response("4.1.2", { status: 200 }),
|
|
|
|
|
) as unknown as typeof fetch;
|
|
|
|
|
const c = new CoolifyClient("https://coolify.test", "tok", fetchImpl);
|
|
|
|
|
await expect(c.version()).resolves.toBe("4.1.2");
|
|
|
|
|
});
|
feat: diff and apply a database's backup schedule (#51)
Backup schedules were write-only, filed under "known limitations" on the
claim that "live Coolify state doesn't expose it back". The parenthesis was
load-bearing and false: a schedule is not on the database's own GET, but it
was never meant to be — it has its own route, GET /databases/{uuid}/backups,
which cast had been POSTing to all along and had simply never read.
The cost was exact. A database created before its `backup:` block was
declared never got one (apply set the schedule only inside the create
branch); a schedule deleted in the UI was invisible; and the `--full` diff
that gates a production cutover passed with an unbacked-up production
database.
Shape settled from the source rather than the vendored spec, which documents
the body as "Content is very complex. Will be implemented later.":
DatabasesController@database_backup_details_uuid (v4.1.2) returns a raw
Eloquent collection — a JSON array of ScheduledDatabaseBackup rows, columns
per $fillable (uuid, enabled, frequency,
database_backup_retention_amount_locally). `frequency` round-trips verbatim:
the controller validates it and stores $request->only(...) unchanged, with no
mutator on the model. The "diffing it would flag spurious drift" fear was a
guess about a read nobody had performed.
- `backup` becomes a diffed field like any other (resolve.ts), replacing the
side channel that carried it around the diff.
- The live side reads the route (coolify.ts, fetchLive), and apply sets the
schedule on UPDATE as well as create — POST or PATCH, decided by a read.
- A disabled schedule is a row that backs nothing up: neither clean nor
absent. cast diffs it and re-enables it.
Degrades honestly, since no live box was probed: an unreachable or
unrecognized response can only ever produce "declared, NOT compared — verify
in the Coolify UI", never invented drift and never a clean bill on an
unread database. On the write side the same failure raises rather than
guessing — POSTing blind would duplicate a schedule that may already exist.
2026-07-14 22:37:01 +00:00
|
|
|
it("reads a database's backup schedules", async () => {
|
|
|
|
|
const c = new CoolifyClient(
|
|
|
|
|
"https://coolify.test",
|
|
|
|
|
"tok",
|
|
|
|
|
mockFetch({ "GET /api/v1/databases/db-1/backups": [row()] }),
|
|
|
|
|
);
|
|
|
|
|
await expect(c.databaseBackupSchedules("db-1")).resolves.toEqual([
|
fix(draft): read backup schedules and emit backup blocks (#75)
--emit-draft still told every reader that backup schedules "are not
exposed by Coolify's API" — the exact pre-#51 claim that issue disproved:
GET /databases/{uuid}/backups is a route, and diff/apply have read it on
every run since. The draft path was never brought along, so it warned
instead of reading, and a rebuild from a draft came up with no backups.
Now the draft loop makes the same supplementary per-database GET
(databaseBackupSchedules) for every DRAFTED database and databaseSpec
emits a real backup: { frequency, retention } block for the one shape
the manifest can express — a single, enabled schedule. Ungated on
purpose: fetchLive's opts.backups gate exists because the read-side
sweeps never look at the answer, and the draft is the sweep that does.
The read stays sequential (like the existing per-resource env GETs) and
a failed read degrades to an UNCAPTURED entry per resource rather than
aborting the whole-instance sweep — a draft's reader is a human, not an
apply about to write.
UNCAPTURED keeps only what the route genuinely cannot answer:
- the S3 target: save_s3 now rides on LiveBackup, and a schedule that
saves to S3 gets a per-database entry saying the target reads back
only as s3_storage_id, an int nothing maps to a storage UUID
- a DISABLED schedule (declaring the block would make apply re-enable it)
- several schedules where a manifest declares one
- an unreadable route (reported, never read as "no backups")
The stale NO_API_COVERAGE "backup schedules" row becomes "a backup
schedule's S3 target", and semantics.md's draft section now tells the
truth about what is captured.
Closes #75
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-16 18:25:34 +00:00
|
|
|
{
|
|
|
|
|
uuid: "sched-1",
|
|
|
|
|
frequency: "0 3 * * *",
|
|
|
|
|
retention: 7,
|
|
|
|
|
enabled: true,
|
|
|
|
|
saveS3: true,
|
|
|
|
|
},
|
feat: diff and apply a database's backup schedule (#51)
Backup schedules were write-only, filed under "known limitations" on the
claim that "live Coolify state doesn't expose it back". The parenthesis was
load-bearing and false: a schedule is not on the database's own GET, but it
was never meant to be — it has its own route, GET /databases/{uuid}/backups,
which cast had been POSTing to all along and had simply never read.
The cost was exact. A database created before its `backup:` block was
declared never got one (apply set the schedule only inside the create
branch); a schedule deleted in the UI was invisible; and the `--full` diff
that gates a production cutover passed with an unbacked-up production
database.
Shape settled from the source rather than the vendored spec, which documents
the body as "Content is very complex. Will be implemented later.":
DatabasesController@database_backup_details_uuid (v4.1.2) returns a raw
Eloquent collection — a JSON array of ScheduledDatabaseBackup rows, columns
per $fillable (uuid, enabled, frequency,
database_backup_retention_amount_locally). `frequency` round-trips verbatim:
the controller validates it and stores $request->only(...) unchanged, with no
mutator on the model. The "diffing it would flag spurious drift" fear was a
guess about a read nobody had performed.
- `backup` becomes a diffed field like any other (resolve.ts), replacing the
side channel that carried it around the diff.
- The live side reads the route (coolify.ts, fetchLive), and apply sets the
schedule on UPDATE as well as create — POST or PATCH, decided by a read.
- A disabled schedule is a row that backs nothing up: neither clean nor
absent. cast diffs it and re-enables it.
Degrades honestly, since no live box was probed: an unreachable or
unrecognized response can only ever produce "declared, NOT compared — verify
in the Coolify UI", never invented drift and never a clean bill on an
unread database. On the write side the same failure raises rather than
guessing — POSTing blind would duplicate a schedule that may already exist.
2026-07-14 22:37:01 +00:00
|
|
|
]);
|
|
|
|
|
});
|
|
|
|
|
// The dangerous 404. fetchLive reads a 404 as "no live environment" three
|
|
|
|
|
// routes up, and that instinct is WRONG here: Coolify answers a database with
|
|
|
|
|
// no schedules with 200 [], never 404 — a 404 means the database wasn't found.
|
|
|
|
|
// Reading it as "no backups" would report an unbacked-up database as clean and
|
|
|
|
|
// make apply POST a duplicate schedule onto one that already had one.
|
|
|
|
|
it("does not turn a failed read into 'this database has no backups'", async () => {
|
|
|
|
|
const c = new CoolifyClient("https://coolify.test", "tok", mockFetch({}));
|
|
|
|
|
await expect(c.databaseBackupSchedules("db-1")).resolves.toBeUndefined();
|
|
|
|
|
});
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
// The shape cast cannot afford to be wrong about. Every unreadable answer must
|
|
|
|
|
// land on `undefined` ("cast cannot say"), and ONLY a genuinely empty list may
|
|
|
|
|
// land on `[]` ("there are none") — the two mean opposite things to every
|
|
|
|
|
// caller downstream, and to the operator staring at a cutover.
|
|
|
|
|
describe("parseBackupSchedules", () => {
|
|
|
|
|
it("reads a well-formed collection", () => {
|
|
|
|
|
expect(parseBackupSchedules([row()])).toEqual([
|
fix(draft): read backup schedules and emit backup blocks (#75)
--emit-draft still told every reader that backup schedules "are not
exposed by Coolify's API" — the exact pre-#51 claim that issue disproved:
GET /databases/{uuid}/backups is a route, and diff/apply have read it on
every run since. The draft path was never brought along, so it warned
instead of reading, and a rebuild from a draft came up with no backups.
Now the draft loop makes the same supplementary per-database GET
(databaseBackupSchedules) for every DRAFTED database and databaseSpec
emits a real backup: { frequency, retention } block for the one shape
the manifest can express — a single, enabled schedule. Ungated on
purpose: fetchLive's opts.backups gate exists because the read-side
sweeps never look at the answer, and the draft is the sweep that does.
The read stays sequential (like the existing per-resource env GETs) and
a failed read degrades to an UNCAPTURED entry per resource rather than
aborting the whole-instance sweep — a draft's reader is a human, not an
apply about to write.
UNCAPTURED keeps only what the route genuinely cannot answer:
- the S3 target: save_s3 now rides on LiveBackup, and a schedule that
saves to S3 gets a per-database entry saying the target reads back
only as s3_storage_id, an int nothing maps to a storage UUID
- a DISABLED schedule (declaring the block would make apply re-enable it)
- several schedules where a manifest declares one
- an unreadable route (reported, never read as "no backups")
The stale NO_API_COVERAGE "backup schedules" row becomes "a backup
schedule's S3 target", and semantics.md's draft section now tells the
truth about what is captured.
Closes #75
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-16 18:25:34 +00:00
|
|
|
{
|
|
|
|
|
uuid: "sched-1",
|
|
|
|
|
frequency: "0 3 * * *",
|
|
|
|
|
retention: 7,
|
|
|
|
|
enabled: true,
|
|
|
|
|
saveS3: true,
|
|
|
|
|
},
|
feat: diff and apply a database's backup schedule (#51)
Backup schedules were write-only, filed under "known limitations" on the
claim that "live Coolify state doesn't expose it back". The parenthesis was
load-bearing and false: a schedule is not on the database's own GET, but it
was never meant to be — it has its own route, GET /databases/{uuid}/backups,
which cast had been POSTing to all along and had simply never read.
The cost was exact. A database created before its `backup:` block was
declared never got one (apply set the schedule only inside the create
branch); a schedule deleted in the UI was invisible; and the `--full` diff
that gates a production cutover passed with an unbacked-up production
database.
Shape settled from the source rather than the vendored spec, which documents
the body as "Content is very complex. Will be implemented later.":
DatabasesController@database_backup_details_uuid (v4.1.2) returns a raw
Eloquent collection — a JSON array of ScheduledDatabaseBackup rows, columns
per $fillable (uuid, enabled, frequency,
database_backup_retention_amount_locally). `frequency` round-trips verbatim:
the controller validates it and stores $request->only(...) unchanged, with no
mutator on the model. The "diffing it would flag spurious drift" fear was a
guess about a read nobody had performed.
- `backup` becomes a diffed field like any other (resolve.ts), replacing the
side channel that carried it around the diff.
- The live side reads the route (coolify.ts, fetchLive), and apply sets the
schedule on UPDATE as well as create — POST or PATCH, decided by a read.
- A disabled schedule is a row that backs nothing up: neither clean nor
absent. cast diffs it and re-enables it.
Degrades honestly, since no live box was probed: an unreachable or
unrecognized response can only ever produce "declared, NOT compared — verify
in the Coolify UI", never invented drift and never a clean bill on an
unread database. On the write side the same failure raises rather than
guessing — POSTing blind would duplicate a schedule that may already exist.
2026-07-14 22:37:01 +00:00
|
|
|
]);
|
|
|
|
|
});
|
|
|
|
|
it("reads an empty list as a trustworthy 'no schedule', not as unknown", () => {
|
|
|
|
|
expect(parseBackupSchedules([])).toEqual([]);
|
|
|
|
|
});
|
|
|
|
|
it("reads the spec's own placeholder body as unknown, not as 'no schedule'", () => {
|
|
|
|
|
// What the vendored OpenAPI literally documents for this route. If Coolify
|
|
|
|
|
// ever really answered this, cast must not read it as "no backups".
|
|
|
|
|
expect(
|
|
|
|
|
parseBackupSchedules(
|
|
|
|
|
"Content is very complex. Will be implemented later.",
|
|
|
|
|
),
|
|
|
|
|
).toBeUndefined();
|
|
|
|
|
});
|
|
|
|
|
it.each([
|
|
|
|
|
["a non-array object", { data: [] }],
|
|
|
|
|
["null", null],
|
|
|
|
|
["a row that is not an object", ["nope"]],
|
|
|
|
|
["a row with no frequency", [row({ frequency: undefined })]],
|
|
|
|
|
["a row with a non-string frequency", [row({ frequency: 3 })]],
|
|
|
|
|
[
|
|
|
|
|
"a row with a null retention",
|
|
|
|
|
[row({ database_backup_retention_amount_locally: null })],
|
|
|
|
|
],
|
|
|
|
|
[
|
|
|
|
|
"a row with a non-numeric retention",
|
|
|
|
|
[row({ database_backup_retention_amount_locally: "many" })],
|
|
|
|
|
],
|
|
|
|
|
])("reads %s as unknown", (_label, body) => {
|
|
|
|
|
expect(parseBackupSchedules(body)).toBeUndefined();
|
|
|
|
|
});
|
|
|
|
|
it("collapses the WHOLE read when any one row is unreadable", () => {
|
|
|
|
|
// A partial list is indistinguishable from a complete one downstream, and
|
|
|
|
|
// the caller worth protecting is the one asking "is this backed up?".
|
|
|
|
|
expect(
|
|
|
|
|
parseBackupSchedules([row(), row({ uuid: 7, frequency: null })]),
|
|
|
|
|
).toBeUndefined();
|
|
|
|
|
});
|
|
|
|
|
it("reads a disabled schedule as disabled, however Coolify spells it", () => {
|
|
|
|
|
// `enabled` has no cast on the model (v4.1.2 casts() covers only the two
|
|
|
|
|
// float storage fields), so a tinyint column can serialize as 1/0.
|
|
|
|
|
expect(parseBackupSchedules([row({ enabled: 0 })])?.[0].enabled).toBe(
|
|
|
|
|
false,
|
|
|
|
|
);
|
|
|
|
|
expect(parseBackupSchedules([row({ enabled: false })])?.[0].enabled).toBe(
|
|
|
|
|
false,
|
|
|
|
|
);
|
|
|
|
|
expect(parseBackupSchedules([row({ enabled: 1 })])?.[0].enabled).toBe(true);
|
|
|
|
|
// Absent reads as enabled: Coolify's create path defaults it to true.
|
|
|
|
|
expect(
|
|
|
|
|
parseBackupSchedules([row({ enabled: undefined })])?.[0].enabled,
|
|
|
|
|
).toBe(true);
|
|
|
|
|
});
|
fix(draft): read backup schedules and emit backup blocks (#75)
--emit-draft still told every reader that backup schedules "are not
exposed by Coolify's API" — the exact pre-#51 claim that issue disproved:
GET /databases/{uuid}/backups is a route, and diff/apply have read it on
every run since. The draft path was never brought along, so it warned
instead of reading, and a rebuild from a draft came up with no backups.
Now the draft loop makes the same supplementary per-database GET
(databaseBackupSchedules) for every DRAFTED database and databaseSpec
emits a real backup: { frequency, retention } block for the one shape
the manifest can express — a single, enabled schedule. Ungated on
purpose: fetchLive's opts.backups gate exists because the read-side
sweeps never look at the answer, and the draft is the sweep that does.
The read stays sequential (like the existing per-resource env GETs) and
a failed read degrades to an UNCAPTURED entry per resource rather than
aborting the whole-instance sweep — a draft's reader is a human, not an
apply about to write.
UNCAPTURED keeps only what the route genuinely cannot answer:
- the S3 target: save_s3 now rides on LiveBackup, and a schedule that
saves to S3 gets a per-database entry saying the target reads back
only as s3_storage_id, an int nothing maps to a storage UUID
- a DISABLED schedule (declaring the block would make apply re-enable it)
- several schedules where a manifest declares one
- an unreadable route (reported, never read as "no backups")
The stale NO_API_COVERAGE "backup schedules" row becomes "a backup
schedule's S3 target", and semantics.md's draft section now tells the
truth about what is captured.
Closes #75
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-16 18:25:34 +00:00
|
|
|
it("reads save_s3 however Coolify spells it — and absent as false", () => {
|
|
|
|
|
// Same tinyint-with-no-cast story as `enabled`, opposite default: "this
|
|
|
|
|
// backup lands in S3" must never be claimed off a field the row lacks.
|
|
|
|
|
expect(parseBackupSchedules([row({ save_s3: 1 })])?.[0].saveS3).toBe(true);
|
|
|
|
|
expect(parseBackupSchedules([row({ save_s3: 0 })])?.[0].saveS3).toBe(false);
|
|
|
|
|
expect(parseBackupSchedules([row({ save_s3: false })])?.[0].saveS3).toBe(
|
|
|
|
|
false,
|
|
|
|
|
);
|
|
|
|
|
expect(
|
|
|
|
|
parseBackupSchedules([row({ save_s3: undefined })])?.[0].saveS3,
|
|
|
|
|
).toBe(false);
|
|
|
|
|
});
|
feat: diff and apply a database's backup schedule (#51)
Backup schedules were write-only, filed under "known limitations" on the
claim that "live Coolify state doesn't expose it back". The parenthesis was
load-bearing and false: a schedule is not on the database's own GET, but it
was never meant to be — it has its own route, GET /databases/{uuid}/backups,
which cast had been POSTing to all along and had simply never read.
The cost was exact. A database created before its `backup:` block was
declared never got one (apply set the schedule only inside the create
branch); a schedule deleted in the UI was invisible; and the `--full` diff
that gates a production cutover passed with an unbacked-up production
database.
Shape settled from the source rather than the vendored spec, which documents
the body as "Content is very complex. Will be implemented later.":
DatabasesController@database_backup_details_uuid (v4.1.2) returns a raw
Eloquent collection — a JSON array of ScheduledDatabaseBackup rows, columns
per $fillable (uuid, enabled, frequency,
database_backup_retention_amount_locally). `frequency` round-trips verbatim:
the controller validates it and stores $request->only(...) unchanged, with no
mutator on the model. The "diffing it would flag spurious drift" fear was a
guess about a read nobody had performed.
- `backup` becomes a diffed field like any other (resolve.ts), replacing the
side channel that carried it around the diff.
- The live side reads the route (coolify.ts, fetchLive), and apply sets the
schedule on UPDATE as well as create — POST or PATCH, decided by a read.
- A disabled schedule is a row that backs nothing up: neither clean nor
absent. cast diffs it and re-enables it.
Degrades honestly, since no live box was probed: an unreachable or
unrecognized response can only ever produce "declared, NOT compared — verify
in the Coolify UI", never invented drift and never a clean bill on an
unread database. On the write side the same failure raises rather than
guessing — POSTing blind would duplicate a schedule that may already exist.
2026-07-14 22:37:01 +00:00
|
|
|
it("accepts an integer retention however it is serialized", () => {
|
|
|
|
|
expect(
|
|
|
|
|
parseBackupSchedules([
|
|
|
|
|
row({ database_backup_retention_amount_locally: "7" }),
|
|
|
|
|
])?.[0].retention,
|
|
|
|
|
).toBe(7);
|
|
|
|
|
});
|
feat: cast — the Coolify executor, extracted from the infra state repo
Public tool, private state. cast holds no hostnames, no bindings, no
secrets: it joins a product repo's .infra/ manifest with a state directory
you point it at, and makes Coolify match.
Extracted from heavy-duty/infra, which was half tool and half state — the
inconsistency that made it impossible to say whether "infra" named a CLI
or a runbook. rig builds the boxes; cast fills them; infra is what they
are filled with.
Two changes were required to make it genuinely stateless and publishable:
- The implicit cwd contract (environments.yaml / secrets/ / .coolify.env
resolved against the working directory, silently reading the wrong file
from the wrong place) is now an explicit --state <dir> / $CAST_STATE.
- BANNED_IN_PROD — a hardcoded list of one product's ALLOW_* flags, the
only product knowledge in the executor — becomes the generic, operator-
owned environments.<env>.forbidden_var_patterns. The guard now lives in
private state, so a product-side change cannot lower its own guard, and
it is a pattern rather than a list, so it catches unforeseen siblings.
Age identities resolve as $CAST_AGE_KEY_FILE_<ENV> then
~/.config/cast/age-<env>.key — which is the entire attended-vs-unattended
apply mechanism, with no environment names known to the tool.
Instance identity (org names, the GitHub App name, founder domains) is out
of the fixtures and out of register-github-app.sh, which took APP_NAME and
ORG as arguments rather than baking them in.
69 tests green; bin/cast + curl installer mirror rig's shape.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-11 12:25:44 +00:00
|
|
|
});
|