upaas now asks Docker for a BuildKit build instead of the classic builder. BuildKit keeps the stages of a multi-stage build in Docker's build cache, which Docker keeps under a size limit and cleans on its own, so no untagged stage images are left after a deploy. The final image is still tagged upaas-<app>:<N>, so the cleanup from #219 works unchanged. BuildKit removes no images.
BuildKit sends its progress as encoded trace messages. These are decoded with BuildKit's own library and written to the deployment log (and stdout) as plain text, the same as docker build --progress=plain shows it. Build errors reach the log as before.
Disclosures:
Deviation: adds github.com/moby/buildkit v0.16.0 (the version Docker Engine 27.3.1 itself uses); go get and go mod tidy were run directly, since no make target adds a dependency.
Judgement call: the cache limit is Docker's own. It is on by default from Docker Engine 28.2; older engines need "builder": {"gc": {"enabled": true}} in daemon.json, noted in the README. The host running fsn1app1 was not checked.
Stdout now shows the build as plain text instead of raw JSON.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/upaas/issues/220.
upaas now asks Docker for a BuildKit build instead of the classic builder. BuildKit keeps the stages of a multi-stage build in Docker's build cache, which Docker keeps under a size limit and cleans on its own, so no untagged stage images are left after a deploy. The final image is still tagged `upaas-<app>:<N>`, so the cleanup from https://git.eeqj.de/sneak/upaas/pulls/219 works unchanged. BuildKit removes no images.
BuildKit sends its progress as encoded trace messages. These are decoded with BuildKit's own library and written to the deployment log (and stdout) as plain text, the same as `docker build --progress=plain` shows it. Build errors reach the log as before.
Disclosures:
- Deviation: adds `github.com/moby/buildkit` v0.16.0 (the version Docker Engine 27.3.1 itself uses); `go get` and `go mod tidy` were run directly, since no make target adds a dependency.
- Judgement call: the cache limit is Docker's own. It is on by default from Docker Engine 28.2; older engines need `"builder": {"gc": {"enabled": true}}` in `daemon.json`, noted in the README. The host running fsn1app1 was not checked.
- Stdout now shows the build as plain text instead of raw JSON.
Model: opus-5-5
The classic builder left an untagged image for every step of every
stage of a multi-stage build. BuildKit keeps stages in Docker's build
cache, which Docker keeps under a size limit on its own. BuildKit
reports progress as encoded trace messages, so these are decoded with
BuildKit's own library and written to the deployment log as plain text.
The README notes that engines older than 28.2 need build cache cleanup
turned on in daemon.json.
Model: opus-5-5
Manual check on the build host (Docker Engine 29.8): I built a two-stage Dockerfile three times, changing the first stage's input each time. Each build used the same BuildKit build request upaas now sends, and after the third build I removed the oldest tag, the way upaas keeps only the current and previous image. After every build, the only new images on the host were the tagged upaas-verify220:<N> images. No untagged stage image appeared, and no dangling image was left. Removing the oldest tag deleted only that image. This exercised the Docker calls, not a full upaas deploy. All test images were removed afterwards.
Model: opus-5-5
Manual check on the build host (Docker Engine 29.8): I built a two-stage Dockerfile three times, changing the first stage's input each time. Each build used the same BuildKit build request upaas now sends, and after the third build I removed the oldest tag, the way upaas keeps only the current and previous image. After every build, the only new images on the host were the tagged `upaas-verify220:<N>` images. No untagged stage image appeared, and no dangling image was left. Removing the oldest tag deleted only that image. This exercised the Docker calls, not a full upaas deploy. All test images were removed afterwards.
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 #220.
upaas now asks Docker for a BuildKit build instead of the classic builder. BuildKit keeps the stages of a multi-stage build in Docker's build cache, which Docker keeps under a size limit and cleans on its own, so no untagged stage images are left after a deploy. The final image is still tagged
upaas-<app>:<N>, so the cleanup from #219 works unchanged. BuildKit removes no images.BuildKit sends its progress as encoded trace messages. These are decoded with BuildKit's own library and written to the deployment log (and stdout) as plain text, the same as
docker build --progress=plainshows it. Build errors reach the log as before.Disclosures:
github.com/moby/buildkitv0.16.0 (the version Docker Engine 27.3.1 itself uses);go getandgo mod tidywere run directly, since no make target adds a dependency."builder": {"gc": {"enabled": true}}indaemon.json, noted in the README. The host running fsn1app1 was not checked.Model: opus-5-5
Manual check on the build host (Docker Engine 29.8): I built a two-stage Dockerfile three times, changing the first stage's input each time. Each build used the same BuildKit build request upaas now sends, and after the third build I removed the oldest tag, the way upaas keeps only the current and previous image. After every build, the only new images on the host were the tagged
upaas-verify220:<N>images. No untagged stage image appeared, and no dangling image was left. Removing the oldest tag deleted only that image. This exercised the Docker calls, not a full upaas deploy. All test images were removed afterwards.Model: opus-5-5
PASS: tested
a0c59aa25e7b0652fca9a32eded671586cd6a39connext2heada60ea144fb0be0df2c67730d7e6a17e329dfc63f.Model: opus-5-5
Gate on
next2ata57efeed12e2148ecc55803ccf4d2eae94b2b794(same tree as the testeda0c59aa):make checkpass.Model: opus-5-5