Files
werkator/docs/prs/2026-10-03-PR#94-mutation-build-fixes.md
miandmhoennig 87775359cf
werkator build succeeded after 02:47
werkator/mutation build succeeded after 38:45
werkator/deploy build succeeded after 00:08
Fixes for the nightly mutation build (v1.29.1) (#94)
## The Problem

The first run of the build `mutation` (PR#93) on mih09, right after the merge on 2026-10-03, failed twice:

- PIT stopped in its coverage run: `BuildExecutorIntegrationTest` did not pass without mutation, although the normal test build on mih09 and PIT locally pass it.
- The deploy of v1.28.0, queued behind it, found no runtime bundle: `mutation` runs in `main`'s worktree, and its `cleanCommand: rm -rf build` deleted the bundle the test build had left there.

The run started at once instead of at 02:00, because the definition was new and the day's slot was due.

## The Solution

- `mutation` cleans only `build/reports/pitest` and `build/reports/codecharta`; PIT recompiles what changed, and the runtime bundle stays for the deploy.
- `mutation` runs at 00:00 UTC instead of 02:00: 01:00 or 02:00 in Germany, depending on daylight saving time, which UTC does not have; later nightly builds of other repositories follow it on mih09.
- `BuildExecutorIntegrationTest` no longer runs under PIT.
  Two probe builds on this branch, with PIT's verbose output, could not reproduce the failure: the spec passed alone and with every other spec.
  It is most likely a timing-dependent case; the best guess is Scenario#67.04, where `true` must use no measurable processor time, which one clock tick under PIT's instrumentation breaks.
  One failing spec in the coverage run aborts the whole night, and the spec costs 24-29 s per covering mutant.
  `BuildExecutor` shows mostly uncovered until its logic moves into unit tests.

## Follow-up PRs

- `BuildExecutor`: its decisions into small classes with unit tests (already planned in PR#93).
- Make the timing-dependent cases of `BuildExecutorIntegrationTest` robust, starting with Scenario#67.04.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: mhoennig <michael@hoennig.de>
Reviewed-on: #94
2026-10-03 14:13:05 +02:00

1.9 KiB

PR#94: Fixes for the Nightly Mutation Build

This document describes the change of this pull request at the time it was made. Later pull requests may change the behaviour without updating it.

The Problem

The first run of the build mutation (PR#93) on mih09, right after the merge on 2026-10-03, failed twice:

  • PIT stopped in its coverage run: BuildExecutorIntegrationTest did not pass without mutation, although the normal test build on mih09 and PIT locally pass it.
  • The deploy of v1.28.0, queued behind it, found no runtime bundle: mutation runs in main's worktree, and its cleanCommand: rm -rf build deleted the bundle the test build had left there.

The run started at once instead of at 02:00, because the definition was new and the day's slot was due.

The Solution

  • mutation cleans only build/reports/pitest and build/reports/codecharta; PIT recompiles what changed, and the runtime bundle stays for the deploy.
  • mutation runs at 00:00 UTC instead of 02:00: 01:00 or 02:00 in Germany, depending on daylight saving time, which UTC does not have; later nightly builds of other repositories follow it on mih09.
  • BuildExecutorIntegrationTest no longer runs under PIT. Two probe builds on this branch, with PIT's verbose output, could not reproduce the failure: the spec passed alone and with every other spec. It is most likely a timing-dependent case; the best guess is Scenario#67.04, where true must use no measurable processor time, which one clock tick under PIT's instrumentation breaks. One failing spec in the coverage run aborts the whole night, and the spec costs 24-29 s per covering mutant. BuildExecutor shows mostly uncovered until its logic moves into unit tests.

Follow-up PRs

  • BuildExecutor: its decisions into small classes with unit tests (already planned in PR#93).
  • Make the timing-dependent cases of BuildExecutorIntegrationTest robust, starting with Scenario#67.04.