Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions assets.lock
Original file line number Diff line number Diff line change
Expand Up @@ -21,16 +21,16 @@ manifest_sha256 = "7bff7252fa38a74fd1a513baffeceb80eaddb556b11eec55438503ac7e9ec
[[tools]]
name = "docker"
group = "docker"
version = "29.6.2"
arch.arm64.sha256 = "86f86ad4b2119ec55aa50224f15ceb4c94a198f8ae153bb32318d7da589749da"
arch.x86_64.sha256 = "9a72a1c1a331885aadf7948e3da8e3c5c88c5e813474bb82dce7cc72450487bf"
version = "29.7.1"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This takes the host CLI to 29.7.1 while boot bundle 0.6.13 still ships dockerd 29.6.1, widening the gap from patch-level to minor-level. The header at lines 11-14 tolerates that divergence only "for the short window between a bundle release and the [boot] bump", but the weekly cron has no awareness of the [boot] half, so nothing closes the window automatically. Almost certainly fine in practice via API negotiation — worth confirming someone owns the follow-up bump.

Technical details
# Host Docker CLI pin now a minor version ahead of the guest dockerd

## Evidence
- Fetched `https://boot.arcboxcdn.com/asset/v0.6.13/manifest.json` (its sha256
  matches the `manifest_sha256` pin on line 19 exactly, so this is the bundle
  this repo actually boots). It pins `dockerd` and `docker-init` at `29.6.1`.
- Before this PR: CLI 29.6.2 vs dockerd 29.6.1 — same minor.
- After this PR: CLI 29.7.1 vs dockerd 29.6.1 — one minor ahead.

## Affected sites
- `assets.lock:24` — the CLI pin this PR moves.
- `assets.lock:11-14` — the rule this crosses: keep the `docker` tool on the
  same version as the boot bundle's dockerd, diverging only briefly.
- `app/arcbox-docker-tools/src/lockfile.rs:5-6` — doc comment asserts "A single
  lockfile ensures the Docker CLI and guest dockerd are always at the same
  version — no version-skew concerns on upgrade." That is not true and this PR
  makes it visibly wrong: dockerd comes from the boot manifest, not
  `[[tools]]`, exactly as `assets.lock`'s own header states.
- `docs/boot-assets.md:13,31` — states the bundle is built from the "Docker
  29.6.1 static package". Accurate for `0.6.13`, so it will need updating in
  the same change that moves `[boot]` to a 29.7.x bundle.

## Required outcome
- A decision on whether merging ahead of the bundle is acceptable here, and if
  so something tracking the follow-up `[boot]` + `manifest_sha256` bump once
  `boot-assets` publishes a 29.7.x-based release.
- Correct or delete the `lockfile.rs:5-6` version-skew claim so it stops
  contradicting `assets.lock`'s header.

## Open questions for the human
- Is the intended sequence "bump `[boot]` first, then let the cron move the
  CLI"? If so, this PR arrived out of order and may be worth holding.
- Should `check-tool-updates` warn when the `docker` tool pin's minor version
  diverges from the pinned bundle's dockerd, so this is caught at generation
  time rather than in review?

arch.arm64.sha256 = "231bc78e848661427925aea1081950ba1bebd1a6f7d4581dc6929ddef7fa7d9d"
arch.x86_64.sha256 = "f7aa447d9b02fc1798df31c73a1f2797d4b23336ff11bce0972b778582ee6526"

[[tools]]
name = "docker-buildx"
group = "docker"
version = "0.35.0"
arch.arm64.sha256 = "fedbcbd488dcdb46414c6119920d8186d406531a1157ceede4e857e25af77ff1"
arch.x86_64.sha256 = "7d53fd11deca2d4caebc5436c9eebece5c81c8bbc6d4b539cf30be5c133c38c7"
version = "0.36.0"
arch.arm64.sha256 = "82c6a3d9df37790c5bdb0d7ca88986d1d17622fc2b88ebe34b275c6c47acd7a6"
arch.x86_64.sha256 = "8a75be22ecf40f633fe0a0199be48fa304c0446a0d7fa8a53d7c71b1d0093028"

[[tools]]
name = "docker-compose"
Expand Down
Loading