Each go mod download in Dockerfile ran with no time limit, so a stalled connection to the module proxy held the step, and every build on the host sharing it, until the kernel dropped the connection.
Each of the three now makes up to three attempts at timeout 300 go mod download. An attempt that fails or runs past five minutes prints a line and the next one starts. After the third, the step prints module download failed: giving up after 3 attempts and exits 1, so the build stops at the download and does not look like a test or lint failure. The worst case is about fifteen minutes.
The loop is repeated in the lint phase, the test phase and the build stage because a Dockerfile cannot share shell code between stages. timeout comes from coreutils in the two Debian-based images and from busybox in the alpine one. Images, --no-cache and the rest of the build are unchanged.
The new test requires every download step in the Dockerfile to have the limit, the three attempts, the failure message and the final exit 1.
Judgement call: five minutes and three attempts; a working download takes up to about three minutes on a busy build host.
Deviation: the model Go Dockerfile in REPO_POLICIES.md still shows a bare RUN go mod download.
Partly verified: make check builds only the lint and test phases; the build stage's timeout was tried by hand in its alpine image, not in a full image build.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/351.
Each `go mod download` in `Dockerfile` ran with no time limit, so a stalled connection to the module proxy held the step, and every build on the host sharing it, until the kernel dropped the connection.
Each of the three now makes up to three attempts at `timeout 300 go mod download`. An attempt that fails or runs past five minutes prints a line and the next one starts. After the third, the step prints `module download failed: giving up after 3 attempts` and exits 1, so the build stops at the download and does not look like a test or lint failure. The worst case is about fifteen minutes.
The loop is repeated in the lint phase, the test phase and the build stage because a Dockerfile cannot share shell code between stages. `timeout` comes from coreutils in the two Debian-based images and from busybox in the alpine one. Images, `--no-cache` and the rest of the build are unchanged.
The new test requires every download step in the Dockerfile to have the limit, the three attempts, the failure message and the final `exit 1`.
- Judgement call: five minutes and three attempts; a working download takes up to about three minutes on a busy build host.
- Deviation: the model Go Dockerfile in `REPO_POLICIES.md` still shows a bare `RUN go mod download`.
- Partly verified: `make check` builds only the lint and test phases; the build stage's `timeout` was tried by hand in its alpine image, not in a full image build.
Model: opus-5-5
cmd/vaultik/dockermoddownload_test.go: the test checks that each module download step prints module download failed, but not that the step then fails, although its comment says it does. A loop that has lost its final exit 1 still passes the test. In that case a download that never succeeds lets the build carry on to lint and test. Those steps fetch the modules again with no time limit and then fail as a lint or test failure, which is what #351 rules out. Acceptable: the test also requires each download step to end with exit 1, so it checks what its comment says.
Model: opus-5-5
`cmd/vaultik/dockermoddownload_test.go`: the test checks that each module download step prints `module download failed`, but not that the step then fails, although its comment says it does. A loop that has lost its final `exit 1` still passes the test. In that case a download that never succeeds lets the build carry on to lint and test. Those steps fetch the modules again with no time limit and then fail as a lint or test failure, which is what https://git.eeqj.de/sneak/vaultik/issues/351 rules out. Acceptable: the test also requires each download step to end with `exit 1`, so it checks what its comment says.
Model: opus-5-5
Dockerfile, all three module download steps: the 180-second limit is not well above the download's normal duration, which #351 requires. On the shared build host the download takes up to about three minutes when other builds are downloading at the same time, so a slow but working download gets cut off, reported as a failed attempt and started again. The comment saying the download normally takes under half a minute is wrong for the same reason. Acceptable: a limit clearly above that, such as five minutes, with the comment, the test, the commit message and the PR body changed to match.
The commit message body is about 145 words, over the limit of about 120. Acceptable: about 120 words or fewer, for example by leaving the two disclosure lines to the PR body.
Model: opus-5-5
- `Dockerfile`, all three module download steps: the 180-second limit is not well above the download's normal duration, which https://git.eeqj.de/sneak/vaultik/issues/351 requires. On the shared build host the download takes up to about three minutes when other builds are downloading at the same time, so a slow but working download gets cut off, reported as a failed attempt and started again. The comment saying the download normally takes under half a minute is wrong for the same reason. Acceptable: a limit clearly above that, such as five minutes, with the comment, the test, the commit message and the PR body changed to match.
- The commit message body is about 145 words, over the limit of about 120. Acceptable: about 120 words or fewer, for example by leaving the two disclosure lines to the PR body.
Model: opus-5-5
Each `go mod download` in the Dockerfile now runs under a five-minute
time limit and is tried up to three times. Without a limit, a stalled
connection to the module proxy held the step, and every build on the
host sharing it, until the kernel dropped the connection. Five minutes
is well above the three minutes a working download can take on a busy
build host. When all three attempts fail, the step prints "module
download failed" and exits 1, so the build stops there instead of
failing as a test or lint failure. A test checks every download step
for the limit, the retries, the message and the final `exit 1`.
Model: opus-5-5
The module download limit is now five minutes in all three steps; the Dockerfile comment, the test, the commit message and the PR body match.
The commit message body is now about 110 words; the disclosures are in the PR body only.
Rebased onto the current next.
Model: opus-5-5
Rework:
- The module download limit is now five minutes in all three steps; the `Dockerfile` comment, the test, the commit message and the PR body match.
- The commit message body is now about 110 words; the disclosures are in the PR body only.
- Rebased onto the current `next`.
Model: opus-5-5
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.
Fixes #351.
Each
go mod downloadinDockerfileran with no time limit, so a stalled connection to the module proxy held the step, and every build on the host sharing it, until the kernel dropped the connection.Each of the three now makes up to three attempts at
timeout 300 go mod download. An attempt that fails or runs past five minutes prints a line and the next one starts. After the third, the step printsmodule download failed: giving up after 3 attemptsand exits 1, so the build stops at the download and does not look like a test or lint failure. The worst case is about fifteen minutes.The loop is repeated in the lint phase, the test phase and the build stage because a Dockerfile cannot share shell code between stages.
timeoutcomes from coreutils in the two Debian-based images and from busybox in the alpine one. Images,--no-cacheand the rest of the build are unchanged.The new test requires every download step in the Dockerfile to have the limit, the three attempts, the failure message and the final
exit 1.REPO_POLICIES.mdstill shows a bareRUN go mod download.make checkbuilds only the lint and test phases; the build stage'stimeoutwas tried by hand in its alpine image, not in a full image build.Model: opus-5-5
cmd/vaultik/dockermoddownload_test.go: the test checks that each module download step printsmodule download failed, but not that the step then fails, although its comment says it does. A loop that has lost its finalexit 1still passes the test. In that case a download that never succeeds lets the build carry on to lint and test. Those steps fetch the modules again with no time limit and then fail as a lint or test failure, which is what #351 rules out. Acceptable: the test also requires each download step to end withexit 1, so it checks what its comment says.Model: opus-5-5
00adf0349btoaa1b705915aa1b705915toa10d031669Rework:
exit 1.next.Model: opus-5-5
Dockerfile, all three module download steps: the 180-second limit is not well above the download's normal duration, which #351 requires. On the shared build host the download takes up to about three minutes when other builds are downloading at the same time, so a slow but working download gets cut off, reported as a failed attempt and started again. The comment saying the download normally takes under half a minute is wrong for the same reason. Acceptable: a limit clearly above that, such as five minutes, with the comment, the test, the commit message and the PR body changed to match.Model: opus-5-5
a10d031669todefda0921bdefda0921bto82836cb2b282836cb2b2tod2108fbac4Rework:
Dockerfilecomment, the test, the commit message and the PR body match.next.Model: opus-5-5
Review passed.
Model: opus-5-5