Infrastructure
The factory registry: what each product pins, checked against its repository
· Toolkit · 2 min read
A product pins our kits in its own repository: the toolkit version in Directory.Build.props, the Keycloak kit in a Dockerfile, the design-system kit in frontend/package.json. Until 11 October nothing recorded which product used which version, or whether a shared change had reached production.
One declaration, checked
On 11 October 2026 we added factory/products.toml, the factory's product registry. For each product it declares the stage, the owner, the integration and production branches, the versions under kits.nuget, kits.keycloak and kits.design_system, and, for a product in production, the deploy job and the commit that production runs.
factory/check_registry.py compares that declaration with each product's repository at origin/<branch>, never the working tree, so unpushed work does not count. --fetch fetches every checkout first; --gitlab asks GitLab for the commit of the newest successful deploy job. Each finding is one line with a verdict. DRIFT means the registry and the repository disagree, and either may be wrong. FAIL marks an operational risk, such as a vendored toolkit, a target framework within 90 days of its end of support, or a design-system pin other than the registry's. Any FAIL or DRIFT makes the script exit with code 1.
What it found on 13 October
The registry's header asks that each change to it go in the same merge request as the change that makes it true. A kit pin cannot follow that rule: the pin changes in the product's repository, the registry in ours. On 12 October the registry recorded Keycloak kit 1.0.1 for Reputo and Leadgener. That evening both moved to 2.0.0. Two merge requests changed the registry the next day; neither touched those lines.
A run on 13 October reported the drift among its other findings:
DRIFT reputo main: Keycloak kit pins ['2.0.0'], registry says 1.0.1
DRIFT leadgener main: Keycloak kit pins ['2.0.0'], registry says 1.0.1
The design-system pins, added to the registry a few hours earlier, matched in both products. The fix is one line per product in products.toml.
For a team building on the toolkit, the registry checks a rule we set for our own upgrades: an upgrade is done when production runs it, not when its merge request merges. With --gitlab, for a product in production, the check reads the toolkit version from the commit GitLab last deployed and warns when it is not the version the registry declares. The registry records, for each product, the kit versions its integration branch pins, and one run of the check shows where that record and the repository disagree.