Builds attached no BuildKit session. BuildKit fetches a base image that is not on the host through the client's session, so on Docker Engine 27 such a build failed with "no active sessions".
Container logs were read raw. Docker sends a container's output in frames with an 8-byte header, so the clone output in the build log and the app logs carried those bytes, and the commit was never read from the clone output (hence "Repository cloned (branch: prod)" in the log on #251).
What changed
performBuild attaches a session the way the docker command line does (github.com/moby/buildkit/session over DialHijack), passes its ID with the build, and closes it when the build ends.
ContainerLogs reads the stream with stdcopy, stdout and stderr in order.
Tests: a fake daemon that fails a build with "no active sessions" unless a session was attached, and a clone whose framed output must come back as plain text with its commit read. Both fail on next.
Disclosures
A failed build already reported its own error on next (#234); the existing TestPerformBuildFails covers it, so nothing changed there.
This host's Docker Engine 29.8 pulls a missing base image even without a session, so the failure and the fix were checked by hand against a Docker Engine 27.3.1 daemon.
The session offers no registry credentials, so base images from private registries still cannot be pulled (out of scope).
No upaas container uses a terminal, so every container log is framed.
Model: opus-5-5
**What was wrong**
- Builds attached no BuildKit session. BuildKit fetches a base image that is not on the host through the client's session, so on Docker Engine 27 such a build failed with "no active sessions".
- Container logs were read raw. Docker sends a container's output in frames with an 8-byte header, so the clone output in the build log and the app logs carried those bytes, and the commit was never read from the clone output (hence "Repository cloned (branch: prod)" in the log on https://git.eeqj.de/sneak/upaas/issues/251).
**What changed**
- `performBuild` attaches a session the way the `docker` command line does (`github.com/moby/buildkit/session` over `DialHijack`), passes its ID with the build, and closes it when the build ends.
- `ContainerLogs` reads the stream with `stdcopy`, stdout and stderr in order.
- Tests: a fake daemon that fails a build with "no active sessions" unless a session was attached, and a clone whose framed output must come back as plain text with its commit read. Both fail on `next`.
**Disclosures**
- A failed build already reported its own error on `next` (https://git.eeqj.de/sneak/upaas/issues/234); the existing `TestPerformBuildFails` covers it, so nothing changed there.
- This host's Docker Engine 29.8 pulls a missing base image even without a session, so the failure and the fix were checked by hand against a Docker Engine 27.3.1 daemon.
- The session offers no registry credentials, so base images from private registries still cannot be pulled (out of scope).
- No upaas container uses a terminal, so every container log is framed.
Model: opus-5-5
Builds now attach a BuildKit session over the Docker API, as the docker
command line does, and pass its ID with the build. BuildKit fetches a base
image that is not on the host through that session; without one, Docker
Engine 27 failed the build with "no active sessions". The session is
closed when the build ends.
Container logs are now read with stdcopy, so the clone output in the build
log and the app logs no longer carry Docker's 8-byte frame headers, and the
commit is read from the clone output; the header in front of the COMMIT
line kept it from being found.
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.
What was wrong
What changed
performBuildattaches a session the way thedockercommand line does (github.com/moby/buildkit/sessionoverDialHijack), passes its ID with the build, and closes it when the build ends.ContainerLogsreads the stream withstdcopy, stdout and stderr in order.next.Disclosures
next(#234); the existingTestPerformBuildFailscovers it, so nothing changed there.Model: opus-5-5
Review passed.
Model: opus-5-5