internal/apierror (3 Nutzer) und internal/httpharden (14 Nutzer): Quelltext identisch zu common (normalisierter Vergleich), interne Kopien geloescht, Importe auf common/<paket>, go.mod/go.sum ergaenzt. internal/archtest/errorleak_test.go: exempt ohne die beiden Pakete (liegen jetzt ausserhalb des Moduls).
Auswirkungen (Pflicht-Review)
Kein Verhaltensunterschied.
Das Root-Modul braucht GOPRIVATE=gitea.perlbach24.de und Lesezugriff aufs Repo bei Einzelbuilds.
Nicht umgestellt: Root-httpclient (strengerer Waechtertest), svcauth und migrate (Quelltext weicht ab), testdb, loadtest.
Tests
131, frisches Wurfverzeichnis (ohne web und die Module): go build, go vet, go test ./... in zwei von drei Wiederholungen ohne jede Ausgabe ausser ok. Im dritten Lauf scheiterten einzelne Pakete mit fork/exec ... text file busy beim Go-Toolchain-Aufruf (Kollision mit dem parallel laufenden Runner auf 131), kein Codefehler. DB-Tests nicht gelaufen (kein TEST_ADMIN_DSN).
Umstellung des Root-Moduls (Karte A-11).
## Umgestellt
`internal/apierror` (3 Nutzer) und `internal/httpharden` (14 Nutzer): Quelltext identisch zu common (normalisierter Vergleich), interne Kopien geloescht, Importe auf `common/<paket>`, `go.mod`/`go.sum` ergaenzt. `internal/archtest/errorleak_test.go`: `exempt` ohne die beiden Pakete (liegen jetzt ausserhalb des Moduls).
## Auswirkungen (Pflicht-Review)
- Kein Verhaltensunterschied.
- Das Root-Modul braucht `GOPRIVATE=gitea.perlbach24.de` und Lesezugriff aufs Repo bei Einzelbuilds.
- Nicht umgestellt: Root-`httpclient` (strengerer Waechtertest), `svcauth` und `migrate` (Quelltext weicht ab), `testdb`, `loadtest`.
## Tests
131, frisches Wurfverzeichnis (ohne web und die Module): `go build`, `go vet`, `go test ./...` in zwei von drei Wiederholungen ohne jede Ausgabe ausser ok. Im dritten Lauf scheiterten einzelne Pakete mit `fork/exec ... text file busy` beim Go-Toolchain-Aufruf (Kollision mit dem parallel laufenden Runner auf 131), kein Codefehler. DB-Tests nicht gelaufen (kein `TEST_ADMIN_DSN`).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
DB-Tests 2026-10-28 auf 204 gegen einen eigenen Wegwerf-Postgres 17 (nicht archivdms, nicht dms_dev). Root-Modul, go test ./cmd/... ./internal/... -p 1: viele DB-Pakete scheitern, identisch auf main (Baseline, Umgebung: die Tests teilen sich die Admin-Datenbank ohne Isolation, Folgelaeufe stossen auf bestehende Tabellen, z. B. module_signing_keys already exists in internal/moduletrust). Gezielt mit drei Wiederholungen auf PR und main verglichen: internal/moduletrust (TestPGStore_*) und internal/archtest (TestAllHTTPServersUseHTTPHarden) scheitern in allen drei Laeufen auf beiden Staenden gleich, internal/svcauth ok. Die Unterschiede im ersten Gesamtlauf (z. B. TestChangePassword_RequiresCurrentPassword) wechseln zwischen den Laeufen und gehen auf die geteilte Datenbank zurueck, nicht auf diesen PR. Der Test-Cluster ist wieder entfernt.
DB-Tests 2026-10-28 auf 204 gegen einen eigenen Wegwerf-Postgres 17 (nicht archivdms, nicht dms_dev). Root-Modul, go test ./cmd/... ./internal/... -p 1: viele DB-Pakete scheitern, **identisch auf main** (Baseline, Umgebung: die Tests teilen sich die Admin-Datenbank ohne Isolation, Folgelaeufe stossen auf bestehende Tabellen, z. B. module_signing_keys already exists in internal/moduletrust). Gezielt mit drei Wiederholungen auf PR und main verglichen: internal/moduletrust (TestPGStore_*) und internal/archtest (TestAllHTTPServersUseHTTPHarden) scheitern in allen drei Laeufen auf beiden Staenden gleich, internal/svcauth ok. Die Unterschiede im ersten Gesamtlauf (z. B. TestChangePassword_RequiresCurrentPassword) wechseln zwischen den Laeufen und gehen auf die geteilte Datenbank zurueck, nicht auf diesen PR. Der Test-Cluster ist wieder entfernt.
Korrektur zur Auswertung oben: Die Root-Fehler in moduletrust, auth, e2e und den migration*-Paketen kamen von meiner Testumgebung. Mehrere Root-Tests bauen die DSN mit strings.Replace(adminDSN, "/postgres?", ...) und setzen eine Admin-Datenbank namens postgres voraus; meine hiess admin_t, daher liefen sie ohne Isolation in der Admin-DB. Der CI-Cluster (#398) nutzt jetzt die Datenbank postgres. Ein Lauf des Root-Moduls mit dieser Konfiguration steht aus.
Korrektur zur Auswertung oben: Die Root-Fehler in moduletrust, auth, e2e und den migration*-Paketen kamen von meiner Testumgebung. Mehrere Root-Tests bauen die DSN mit strings.Replace(adminDSN, "/postgres?", ...) und setzen eine Admin-Datenbank namens postgres voraus; meine hiess admin_t, daher liefen sie ohne Isolation in der Admin-DB. Der CI-Cluster (#398) nutzt jetzt die Datenbank postgres. Ein Lauf des Root-Moduls mit dieser Konfiguration steht aus.
patrick
merged commit bec1fb3cae into main2026-10-28 10:41:54 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Umstellung des Root-Moduls (Karte A-11).
Umgestellt
internal/apierror(3 Nutzer) undinternal/httpharden(14 Nutzer): Quelltext identisch zu common (normalisierter Vergleich), interne Kopien geloescht, Importe aufcommon/<paket>,go.mod/go.sumergaenzt.internal/archtest/errorleak_test.go:exemptohne die beiden Pakete (liegen jetzt ausserhalb des Moduls).Auswirkungen (Pflicht-Review)
GOPRIVATE=gitea.perlbach24.deund Lesezugriff aufs Repo bei Einzelbuilds.httpclient(strengerer Waechtertest),svcauthundmigrate(Quelltext weicht ab),testdb,loadtest.Tests
131, frisches Wurfverzeichnis (ohne web und die Module):
go build,go vet,go test ./...in zwei von drei Wiederholungen ohne jede Ausgabe ausser ok. Im dritten Lauf scheiterten einzelne Pakete mitfork/exec ... text file busybeim Go-Toolchain-Aufruf (Kollision mit dem parallel laufenden Runner auf 131), kein Codefehler. DB-Tests nicht gelaufen (keinTEST_ADMIN_DSN).🤖 Generated with Claude Code
DB-Tests 2026-10-28 auf 204 gegen einen eigenen Wegwerf-Postgres 17 (nicht archivdms, nicht dms_dev). Root-Modul, go test ./cmd/... ./internal/... -p 1: viele DB-Pakete scheitern, identisch auf main (Baseline, Umgebung: die Tests teilen sich die Admin-Datenbank ohne Isolation, Folgelaeufe stossen auf bestehende Tabellen, z. B. module_signing_keys already exists in internal/moduletrust). Gezielt mit drei Wiederholungen auf PR und main verglichen: internal/moduletrust (TestPGStore_*) und internal/archtest (TestAllHTTPServersUseHTTPHarden) scheitern in allen drei Laeufen auf beiden Staenden gleich, internal/svcauth ok. Die Unterschiede im ersten Gesamtlauf (z. B. TestChangePassword_RequiresCurrentPassword) wechseln zwischen den Laeufen und gehen auf die geteilte Datenbank zurueck, nicht auf diesen PR. Der Test-Cluster ist wieder entfernt.
Korrektur zur Auswertung oben: Die Root-Fehler in moduletrust, auth, e2e und den migration*-Paketen kamen von meiner Testumgebung. Mehrere Root-Tests bauen die DSN mit strings.Replace(adminDSN, "/postgres?", ...) und setzen eine Admin-Datenbank namens postgres voraus; meine hiess admin_t, daher liefen sie ohne Isolation in der Admin-DB. Der CI-Cluster (#398) nutzt jetzt die Datenbank postgres. Ein Lauf des Root-Moduls mit dieser Konfiguration steht aus.