docs(ci): correct the #154 hypothesis — the database is wiped before the tests start (#154) #166

2026-08-24T15:02:31-05:00

bermudalamb commented

2026-08-24 15:02:31 -05:00

dmesg came back empty, and the evidence that actually settles it was in the original log the whole time. Step 7 Run migrations succeeded, then step 9's globalSetup applied all six migrations again from scratch. Both point at the same database — migrate.js reads PGHOST/PGDATABASE and the job sets those and TEST_PG* to the same service and the same redefined_test — so had step 7 migrated it, globalSetup would have printed "No migrations to run!", which is what a local run prints.

It found an empty database. The wipe was already happening before the tests started, which makes this a database being reset repeatedly rather than a container dying partway through a heavy run, and accounts cleanly for the empty dmesg: a restart is not a kill.

The suspect moves from memory pressure to the runner's handling of services:, where act_runner has been uneven across releases. The diagnostics change with it: A3 is dropped because it was designed to catch starvation, A2 is demoted to a fallback, and the new first check needs nothing but the Gitea UI — compare step 7 and step 9's migration output in any failing run.

The superseded hypothesis is kept rather than deleted. A future reader finding memory ruled out is better served by seeing why it was suspected and what refuted it than by a document that never mentions it.

Refs #154

dmesg came back empty, and the evidence that actually settles it was in the original log the whole time. Step 7 `Run migrations` succeeded, then step 9's globalSetup applied all six migrations again from scratch. Both point at the same database — migrate.js reads PGHOST/PGDATABASE and the job sets those and TEST_PG* to the same service and the same redefined_test — so had step 7 migrated it, globalSetup would have printed "No migrations to run!", which is what a local run prints. It found an empty database. The wipe was already happening before the tests started, which makes this a database being reset repeatedly rather than a container dying partway through a heavy run, and accounts cleanly for the empty dmesg: a restart is not a kill. The suspect moves from memory pressure to the runner's handling of `services:`, where act_runner has been uneven across releases. The diagnostics change with it: A3 is dropped because it was designed to catch starvation, A2 is demoted to a fallback, and the new first check needs nothing but the Gitea UI — compare step 7 and step 9's migration output in any failing run. The superseded hypothesis is kept rather than deleted. A future reader finding memory ruled out is better served by seeing why it was suspected and what refuted it than by a document that never mentions it. Refs #154

bermudalamb self-assigned this 2026-08-24 15:02:31 -05:00

bermudalamb added this to the Code Quality and Hardening 2 project 2026-08-24 15:02:31 -05:00

bermudalamb added 1 commit 2026-08-24 15:02:31 -05:00

docs(ci): correct the #154 hypothesis — the database is wiped before the tests start (#154 )

SonarQube Analysis / sonarqube (pull_request) Failing after 5m42s

Details

Linting / lint (pull_request) Successful in 2m13s

Details

457ecbfb2b

dmesg came back empty, and the evidence that actually settles it was in the original log the whole time. Step 7 `Run migrations` succeeded, then step 9's globalSetup applied all six migrations again from scratch. Both point at the same database — migrate.js reads PGHOST/PGDATABASE and the job sets those and TEST_PG* to the same service and the same redefined_test — so had step 7 migrated it, globalSetup would have printed "No migrations to run!", which is what a local run prints.

It found an empty database. The wipe was already happening before the tests started, which makes this a database being reset repeatedly rather than a container dying partway through a heavy run, and accounts cleanly for the empty dmesg: a restart is not a kill.

The suspect moves from memory pressure to the runner's handling of `services:`, where act_runner has been uneven across releases. The diagnostics change with it: A3 is dropped because it was designed to catch starvation, A2 is demoted to a fallback, and the new first check needs nothing but the Gitea UI — compare step 7 and step 9's migration output in any failing run.

The superseded hypothesis is kept rather than deleted. A future reader finding memory ruled out is better served by seeing why it was suspected and what refuted it than by a document that never mentions it.

Refs #154

bermudalamb added 1 commit 2026-08-24 15:02:50 -05:00

Merge branch 'main' into feature/154-correct-hypothesis

SonarQube Analysis / sonarqube (pull_request) Failing after 4m57s

Details

Linting / lint (pull_request) Successful in 1m56s

Details

2ee2cce306

bermudalamb moved this to Review in Code Quality and Hardening 2 on 2026-08-24 15:03:02 -05:00

bermudalamb merged commit 1f470c0c02 into main

2026-08-24 15:03:09 -05:00

bermudalamb deleted branch feature/154-correct-hypothesis

2026-08-24 15:03:09 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#166