Directorium/Api

Fork 0

The Core dependency points at a dead host, and the lock still points at GitHub #147

New issue

Open

opened 2026-08-03 19:43:00 +00:00 by manlycucumber · 1 comment

manlycucumber commented

2026-08-03 19:43:00 +00:00

Owner

CI has been red here since 2026-07-12. Until today that was hidden behind two infrastructure faults — the runner could not fetch shivammathur/setup-php, and a deploy.yml that is not valid YAML failed a check on every push (fixed in 273d897). With both cleared, ci / check ran for the first time in three weeks and found a real problem:

./composer.json is valid but your composer.lock has some errors
# Lock file errors
- The lock file is not up to date with the latest changes in composer.json,
  it is recommended that you run `composer update` or `composer update <package name>`.

composer validate --strict is the first step of the job, so nothing after it has run since — not the lint, not PHPStan, not PHPUnit.

Two faults, one commit

fdaf5a0 "chore: point the Core composer dependency at Forgejo" changed exactly one line and nothing else:

 "repositories": [
     {
         "type": "vcs",
-        "url": "https://github.com/DirectoriumApp/Core"
+        "url": "https://git.manlycucumber.com/Directorium/Core"

1. That host does not exist.

$ getent hosts git.manlycucumber.com
(no answer)
$ curl https://git.manlycucumber.com/Directorium/Core
Could not resolve host: git.manlycucumber.com

The estate moved off manlycucumber.com to conditor.dev/ite.gg in July 2026. Forgejo is git.conditor.dev publicly, 10.0.2.21:3000 on the LAN. A sweep of every composer.json, composer.lock and package.json across all 38 estate repos found this as the only remaining reference to the old domain.

2. composer.lock was never regenerated, which is the error CI reports — and it means the lock still resolves Core from GitHub, not from Forgejo at all:

"name": "directorium/core", "version": "dev-develop",
"source": { "url": "https://github.com/DirectoriumApp/Core.git" },
"dist":   { "url": "https://api.github.com/repos/DirectoriumApp/Core/zipball/42ef21b…" }

So the commit's stated intent — point Core at Forgejo — did not take effect. composer.json names a dead host, the lock names GitHub, and the two disagree, which is precisely what --strict is complaining about.

The fix

# in composer.json
"url": "https://git.conditor.dev/Directorium/Core"
composer update directorium/core --lock   # or a full `composer update`

It needs an environment with composer and network reach to Forgejo, which is why this is a report rather than a patch — there is no PHP toolchain on the host that found it. Worth confirming that a private Forgejo repo is reachable by whatever credential CI has before assuming the URL swap alone is enough; if it is not, the repo may need to be public, or the workflow needs a token.

273d897 — the invalid deploy.yml, fixed here and in Directorium/Ordo and Directorium/Site.
8c154c8 — workflow_dispatch on ci.yml, so a build can be re-run without a commit invented to push the button.
Directorium/Core's own develop is green, so Core itself is fine.

CI has been red here since 2026-07-12. Until today that was hidden behind two infrastructure faults — the runner could not fetch `shivammathur/setup-php`, and a `deploy.yml` that is not valid YAML failed a check on every push (fixed in `273d897`). With both cleared, `ci / check` ran for the first time in three weeks and found a real problem: ``` ./composer.json is valid but your composer.lock has some errors # Lock file errors - The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update` or `composer update <package name>`. ``` `composer validate --strict` is the first step of the job, so nothing after it has run since — not the lint, not PHPStan, not PHPUnit. ## Two faults, one commit `fdaf5a0` "chore: point the Core composer dependency at Forgejo" changed exactly one line and nothing else: ```diff "repositories": [ { "type": "vcs", - "url": "https://github.com/DirectoriumApp/Core" + "url": "https://git.manlycucumber.com/Directorium/Core" ``` **1. That host does not exist.** ``` $ getent hosts git.manlycucumber.com (no answer) $ curl https://git.manlycucumber.com/Directorium/Core Could not resolve host: git.manlycucumber.com ``` The estate moved off `manlycucumber.com` to `conditor.dev`/`ite.gg` in July 2026. Forgejo is `git.conditor.dev` publicly, `10.0.2.21:3000` on the LAN. A sweep of every `composer.json`, `composer.lock` and `package.json` across all 38 estate repos found this as the **only** remaining reference to the old domain. **2. `composer.lock` was never regenerated**, which is the error CI reports — and it means the lock still resolves Core from GitHub, not from Forgejo at all: ```json "name": "directorium/core", "version": "dev-develop", "source": { "url": "https://github.com/DirectoriumApp/Core.git" }, "dist": { "url": "https://api.github.com/repos/DirectoriumApp/Core/zipball/42ef21b…" } ``` So the commit's stated intent — point Core at Forgejo — did not take effect. `composer.json` names a dead host, the lock names GitHub, and the two disagree, which is precisely what `--strict` is complaining about. ## The fix ```bash # in composer.json "url": "https://git.conditor.dev/Directorium/Core" composer update directorium/core --lock # or a full `composer update` ``` It needs an environment with composer and network reach to Forgejo, which is why this is a report rather than a patch — there is no PHP toolchain on the host that found it. Worth confirming that a private Forgejo repo is reachable by whatever credential CI has before assuming the URL swap alone is enough; if it is not, the repo may need to be public, or the workflow needs a token. ## Related - `273d897` — the invalid `deploy.yml`, fixed here and in `Directorium/Ordo` and `Directorium/Site`. - `8c154c8` — `workflow_dispatch` on `ci.yml`, so a build can be re-run without a commit invented to push the button. - `Directorium/Core`'s own `develop` is green, so Core itself is fine.

manlycucumber commented

2026-08-05 20:00:26 +00:00

Author

Owner

Confirmed independently from the Core side today, and the right fix has changed since this was written.

Re-verified: composer.json still names git.manlycucumber.com; composer.lock still carries "url": "https://github.com/DirectoriumApp/Core.git" at "reference": "42ef21b…"; composer validate --strict is still ci.yml's first step, so it still gates everything behind it. Same toolchain constraint here — no PHP, no Composer, so this stays a report rather than a patch.

What's new: Directorium/Core cut v0.1.0 today (7416bbd, tagged 2026-08-05, release automation moved to git-cliff in #508). So the lock no longer has to chase dev-develop. Pinning a released tag is the better answer now:

"directorium/core": "^0.1.0"

That trades an unpinnable moving branch for a real version constraint, and it's worth deciding in this issue rather than regenerating the lock against dev-develop and revisiting later.

Two consequences worth flagging before someone runs the update:

This is not only a host fix. The lock pins Core at 42ef21b, hundreds of commits behind. Regenerating it pulls in the entire v1.2 Office/text layer — the additive office block on the day contract, and the whole per-annum Little Office. The live API currently serves none of that. So the first green ci / check here is also the first evidence the Api survives the office work; expect to actually read the PHPUnit output, not just watch it go green.
The contract is additive, so this should hold — office was added under SHAPE_VERSION 1.1.0 with the frozen key-set pinned by ContractShapeTest, and CoreGateway passes Core's day contract through untouched. Worth confirming rather than assuming, since it has never once been exercised against a Core this new.

Unrelated but adjacent, from Api/src/Engine/CoreGateway.php:46: MIN_YEAR = 1583 against Core's proven floor of 1584 (Core's own resolveYear(1583) is tracked as Directorium/Core#415). Whether a 1583 request errors cleanly or reaches into pre-floor territory is still unverified, and a lock update would be a natural moment to test it.

This issue has no milestone; given it is the sole thing keeping Api CI red, it probably wants one.

Confirmed independently from the Core side today, and **the right fix has changed since this was written.** Re-verified: `composer.json` still names `git.manlycucumber.com`; `composer.lock` still carries `"url": "https://github.com/DirectoriumApp/Core.git"` at `"reference": "42ef21b…"`; `composer validate --strict` is still `ci.yml`'s first step, so it still gates everything behind it. Same toolchain constraint here — no PHP, no Composer, so this stays a report rather than a patch. **What's new: `Directorium/Core` cut `v0.1.0` today** (`7416bbd`, tagged 2026-08-05, release automation moved to git-cliff in #508). So the lock no longer has to chase `dev-develop`. Pinning a released tag is the better answer now: ```json "directorium/core": "^0.1.0" ``` That trades an unpinnable moving branch for a real version constraint, and it's worth deciding *in this issue* rather than regenerating the lock against `dev-develop` and revisiting later. **Two consequences worth flagging before someone runs the update:** 1. **This is not only a host fix.** The lock pins Core at `42ef21b`, hundreds of commits behind. Regenerating it pulls in the entire v1.2 Office/text layer — the additive `office` block on the day contract, and the whole per-annum Little Office. The live API currently serves **none** of that. So the first green `ci / check` here is also the first evidence the Api survives the office work; expect to actually read the PHPUnit output, not just watch it go green. 2. **The contract is additive, so this should hold** — `office` was added under `SHAPE_VERSION 1.1.0` with the frozen key-set pinned by `ContractShapeTest`, and `CoreGateway` passes Core's day contract through untouched. Worth confirming rather than assuming, since it has never once been exercised against a Core this new. Unrelated but adjacent, from `Api/src/Engine/CoreGateway.php:46`: `MIN_YEAR = 1583` against Core's proven floor of **1584** (Core's own `resolveYear(1583)` is tracked as `Directorium/Core#415`). Whether a 1583 request errors cleanly or reaches into pre-floor territory is still unverified, and a lock update would be a natural moment to test it. This issue has no milestone; given it is the sole thing keeping Api CI red, it probably wants one.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Directorium/Api#147

No description provided.

Rows
Columns