feature: the tfvars store keeps Terraform modules, their instances and the instances' variable files in PostgreSQL.
Release / release (push) Failing after 17m10s

This commit is contained in:
slawek committed 2026-10-28 23:58:54 +01:00
1 parent 97c46ff0d8
commit 3d3a700f11
13 files changed
+667 -8

No files matched your search

+23
View File
@@ -95,3 +95,26 @@ object can be written one after the other. The kind stays the store's, not a fie
Consequences: A key of `config.json` holding a dot cannot be the key of a store. A single key
reads and writes as before, so applications of one-key stores need no change. The application
checks the object of a path, such as the keys it allows in it, itself.
## ADR-5: Terraform modules, instances and their variable files are tables shared through the toolkit
Status: Accepted
Context: Cloud Platform deploys many instances of many Terraform modules, and each module's
configurator, a separate application, edits the variables of its instances. Both have to read
and write the same modules, instances and variable files, with the same versions, so that a
write from an outdated read is refused whichever application made it.
Decision: The toolkit holds the tables and their functions and procedures,
`server/sql/tfvars_store.sql`, and `createTfvarsStore`, which both applications use with their own
`pg` pool. An instance names the schema of its state, unique among instances. A variable file is
a row of its instance, its object as `jsonb` with the one it replaced. The version of an
instance's files is the name and the SHA-256 of each file's text, `tfvarsText` of its object, in
name order; a write locks the table, compares the version and writes in one transaction. A change
the tables refuse is an `HttpError` with the status the routes answer. `pg` is an optional peer
dependency, as the applications that do not use the store do not need it.
Consequences: Every application of the store works on the same rows and refuses the same
conflicts, and changes of the tables reach them with a release of the toolkit. The objects' keys
are in `jsonb`'s order. The store is tested against a real PostgreSQL server, which the release
workflow does not have, so `npm test` runs on the developer's machine.