fleetd CI: unreadableFileIsUnknown is red on main under root #614

2026-09-20T12:41:03+02:00

agent commented

2026-09-20 12:41:03 +02:00

LeadContextGaugeTest.unreadableFileIsUnknown is RED on main in Gitea CI (root inside the container ignores the read bit that setReadable(false) clears, so the file opens anyway and the gauge reports OK instead of UNKNOWN). Measured: CI run 1887, job 3104, commit fa62e99 on main, failure at LeadContextGaugeTest.java:142 (expected UNKNOWN, was OK).

Fix is test-only: after setReadable(false) (kept as the setup guard for a filesystem that refuses the chmod), assert Files.isReadable(file) is false via assumeFalse before constructing the gauge, with a comment explaining a skip here means "could not create the condition", not "the behaviour is fine". The finally block that restores the bit is unchanged, so @TempDir cleanup still works.

Production code (LeadContextGauge.java) is untouched.

Tests run (mvn -o clean install, fleetd/): Tests run: 1841, Failures: 0, Errors: 0, Skipped: 0 -- BUILD SUCCESS. LeadContextGaugeTest itself: Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 (confirms the assumption does not skip on this non-root Mac).

Mutation proof: temporarily made the IOException catch in LeadContextGauge.readUncached return an OK Reading instead of UNKNOWN, ran mvn -o test -Dtest=LeadContextGaugeTest -- unreadableFileIsUnknown FAILED (expected: but was: , Tests run: 9, Failures: 1). Reverted the production file with git checkout and confirmed git diff --stat shows only the test file changed before committing.

LeadContextGaugeTest.unreadableFileIsUnknown is RED on main in Gitea CI (root inside the container ignores the read bit that setReadable(false) clears, so the file opens anyway and the gauge reports OK instead of UNKNOWN). Measured: CI run 1887, job 3104, commit fa62e99 on main, failure at LeadContextGaugeTest.java:142 (expected UNKNOWN, was OK). Fix is test-only: after setReadable(false) (kept as the setup guard for a filesystem that refuses the chmod), assert Files.isReadable(file) is false via assumeFalse before constructing the gauge, with a comment explaining a skip here means "could not create the condition", not "the behaviour is fine". The finally block that restores the bit is unchanged, so @TempDir cleanup still works. Production code (LeadContextGauge.java) is untouched. Tests run (mvn -o clean install, fleetd/): Tests run: 1841, Failures: 0, Errors: 0, Skipped: 0 -- BUILD SUCCESS. LeadContextGaugeTest itself: Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 (confirms the assumption does not skip on this non-root Mac). Mutation proof: temporarily made the IOException catch in LeadContextGauge.readUncached return an OK Reading instead of UNKNOWN, ran mvn -o test -Dtest=LeadContextGaugeTest -- unreadableFileIsUnknown FAILED (expected: <UNKNOWN> but was: <OK>, Tests run: 9, Failures: 1). Reverted the production file with git checkout and confirmed git diff --stat shows only the test file changed before committing.

agent added 1 commit 2026-09-20 12:41:04 +02:00

fleetd CI: skip unreadableFileIsUnknown honestly when root ignores the read bit

CI / shell-tests (pull_request) Failing after 7s

Details

CI / contract (pull_request) Successful in 50s

Details

CI / build (pull_request) Successful in 2m27s

Details

bad47a8444

The test set the file's read bit off via setReadable(false), but on the
Gitea CI runner (root inside the container) the OS ignores that bit and
opens the file anyway, so the test asserted on a condition it never
actually created (LeadContextGaugeTest.java:142 UNKNOWN vs OK, CI run
1887 job 3104, commit fa62e99 on main).

Add Files.isReadable(file) after setReadable(false) and before the gauge
runs, and assumeFalse on it: a skip means "could not set up the case",
never "the behaviour is fine". Restores the read bit either way so
@TempDir cleanup still works.

ltms merged commit 076cc43f7b into main

2026-09-20 12:43:44 +02:00

ltms deleted branch worker/task-7-e34002-7

2026-09-20 12:43:44 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fleet/fleetd#614