config: a blank credential must not disable an inherited one #51

2026-09-11T06:28:01+02:00

mi commented

2026-09-11 06:28:01 +02:00

Five of six repositories on the production instance reported no commit
status to Gitea, silently. The cause was a placeholder: init wrote every
machine config with account: "" and token: "", the machine layer always
wins, and those empty values overrode the instance-wide defaults.git.
GiteaClient found no token and stayed quiet, because publishing a status
is non-fatal by design. The one repository that worked was the one whose
machine config happened to have no git block.

It reproduced itself, too: repo-add runs init, so every repository added
to an instance arrived with its inherited credentials already disabled.

Fixed at both ends. ConfigLoader drops a blank git.account/git.token from
a repository layer instead of letting it shadow the defaults below, and
names the file once — a credential is the one value that cannot mean
anything when empty, while an empty setting can be a choice, which
Scenario#51.04 pins down. That is also what repairs a running
installation: the next start inherits correctly with no file edited.

InitCommand writes the git block commented out, with the detected account
offered inside the comment. A template that asserts token: "" makes a
claim it has no basis for. loadFile then had to learn that a file of
nothing but comments is a layer that sets nothing — readValue answers
such a file with "No content to map" — which parseYaml has always done
for the branch layer.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Five of six repositories on the production instance reported no commit status to Gitea, silently. The cause was a placeholder: init wrote every machine config with account: "" and token: "", the machine layer always wins, and those empty values overrode the instance-wide defaults.git. GiteaClient found no token and stayed quiet, because publishing a status is non-fatal by design. The one repository that worked was the one whose machine config happened to have no git block. It reproduced itself, too: repo-add runs init, so every repository added to an instance arrived with its inherited credentials already disabled. Fixed at both ends. ConfigLoader drops a blank git.account/git.token from a repository layer instead of letting it shadow the defaults below, and names the file once — a credential is the one value that cannot mean anything when empty, while an empty setting can be a choice, which Scenario#51.04 pins down. That is also what repairs a running installation: the next start inherits correctly with no file edited. InitCommand writes the git block commented out, with the detected account offered inside the comment. A template that asserts token: "" makes a claim it has no basis for. loadFile then had to learn that a file of nothing but comments is a layer that sets nothing — readValue answers such a file with "No content to map" — which parseYaml has always done for the branch layer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi added 1 commit 2026-09-11 06:28:02 +02:00

config: a blank credential must not disable an inherited one

werkator build succeeded after 01:34

Details

83606422f2

Five of six repositories on the production instance reported no commit
status to Gitea, silently. The cause was a placeholder: init wrote every
machine config with account: "" and token: "", the machine layer always
wins, and those empty values overrode the instance-wide defaults.git.
GiteaClient found no token and stayed quiet, because publishing a status
is non-fatal by design. The one repository that worked was the one whose
machine config happened to have no git block.

It reproduced itself, too: repo-add runs init, so every repository added
to an instance arrived with its inherited credentials already disabled.

Fixed at both ends. ConfigLoader drops a blank git.account/git.token from
a repository layer instead of letting it shadow the defaults below, and
names the file once — a credential is the one value that cannot mean
anything when empty, while an empty setting can be a choice, which
Scenario#51.04 pins down. That is also what repairs a running
installation: the next start inherits correctly with no file edited.

InitCommand writes the git block commented out, with the detected account
offered inside the comment. A template that asserts token: "" makes a
claim it has no basis for. loadFile then had to learn that a file of
nothing but comments is a layer that sets nothing — readValue answers
such a file with "No content to map" — which parseYaml has always done
for the branch layer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi merged commit 1f14f71fb3 into main

2026-09-11 06:28:38 +02:00

mi deleted branch fix/blank-config-values

2026-09-11 06:28:38 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkator#51