Rewords the comment above --health-interval=1s in script/docker-smoke so it says what the flag does on current Docker. Closes #132.
The old comment said the flag keeps the image's 30-second interval from pushing the first probe past the 30-second wait. From Docker 25 on, probes during the image's 10-second start period run every 5 seconds, so the first probe comes about 5 seconds in with or without the flag. What the flag does is make probes after the start period come every second instead of every 30, so a service that takes longer than 10 seconds to start is still seen as healthy within the wait.
Checked on Docker 29.8.0 (client and daemon) by starting containers with the image's health settings, with and without each flag, and reading when Docker ran each probe.
Judgement call: kept --health-interval=1s instead of switching to --health-start-interval=1s. On its own that flag leaves probes after the start period 30 seconds apart, so a start slower than 10 seconds would miss the wait. It also needs Docker 25 or newer on every machine that runs the script, and I did not check the CI runner's version.
Deviation: TODO.md is not updated, because the issue limits the change to script/docker-smoke.
Model: opus-5-5
Rewords the comment above `--health-interval=1s` in `script/docker-smoke` so it says what the flag does on current Docker. Closes https://git.eeqj.de/sneak/pixa/issues/132.
The old comment said the flag keeps the image's 30-second interval from pushing the first probe past the 30-second wait. From Docker 25 on, probes during the image's 10-second start period run every 5 seconds, so the first probe comes about 5 seconds in with or without the flag. What the flag does is make probes after the start period come every second instead of every 30, so a service that takes longer than 10 seconds to start is still seen as healthy within the wait.
Checked on Docker 29.8.0 (client and daemon) by starting containers with the image's health settings, with and without each flag, and reading when Docker ran each probe.
- Judgement call: kept `--health-interval=1s` instead of switching to `--health-start-interval=1s`. On its own that flag leaves probes after the start period 30 seconds apart, so a start slower than 10 seconds would miss the wait. It also needs Docker 25 or newer on every machine that runs the script, and I did not check the CI runner's version.
- Deviation: `TODO.md` is not updated, because the issue limits the change to `script/docker-smoke`.
Model: opus-5-5
The old comment said the flag stops the image's 30-second interval from
delaying the first probe past the wait. From Docker 25 on, the first
probe runs 5 seconds after start either way; the flag makes probes
after the 10-second start period come every second instead of every
30. Only the comment changes; TODO.md is left alone because the issue
limits the change to this script.
Model: opus-5-5
PASS: the new comment matches what Docker 29.8.0 does with the image's health settings, and keeping --health-interval=1s is the right choice, because --health-start-interval=1s alone would miss the 30-second wait on a start slower than 10 seconds.
Model: opus-5-5
PASS: the new comment matches what Docker 29.8.0 does with the image's health settings, and keeping `--health-interval=1s` is the right choice, because `--health-start-interval=1s` alone would miss the 30-second wait on a start slower than 10 seconds.
Model: opus-5-5
clawbot
merged commit 582ff66ba6 into next2026-09-28 15:48:53 +02: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.
Rewords the comment above
--health-interval=1sinscript/docker-smokeso it says what the flag does on current Docker. Closes #132.The old comment said the flag keeps the image's 30-second interval from pushing the first probe past the 30-second wait. From Docker 25 on, probes during the image's 10-second start period run every 5 seconds, so the first probe comes about 5 seconds in with or without the flag. What the flag does is make probes after the start period come every second instead of every 30, so a service that takes longer than 10 seconds to start is still seen as healthy within the wait.
Checked on Docker 29.8.0 (client and daemon) by starting containers with the image's health settings, with and without each flag, and reading when Docker ran each probe.
--health-interval=1sinstead of switching to--health-start-interval=1s. On its own that flag leaves probes after the start period 30 seconds apart, so a start slower than 10 seconds would miss the wait. It also needs Docker 25 or newer on every machine that runs the script, and I did not check the CI runner's version.TODO.mdis not updated, because the issue limits the change toscript/docker-smoke.Model: opus-5-5
PASS: the new comment matches what Docker 29.8.0 does with the image's health settings, and keeping
--health-interval=1sis the right choice, because--health-start-interval=1salone would miss the 30-second wait on a start slower than 10 seconds.Model: opus-5-5