Skip to content

[build] Wire up SONIC_USE_DOCKER_BUILDKIT for parallel Docker layer builds#25705

Closed
rustiqly wants to merge 1 commit intosonic-net:masterfrom
rustiqly:feat/docker-buildkit
Closed

[build] Wire up SONIC_USE_DOCKER_BUILDKIT for parallel Docker layer builds#25705
rustiqly wants to merge 1 commit intosonic-net:masterfrom
rustiqly:feat/docker-buildkit

Conversation

@rustiqly
Copy link
Contributor

What I did

Wired up the existing SONIC_USE_DOCKER_BUILDKIT config variable to actually enable Docker BuildKit by exporting DOCKER_BUILDKIT=1.

Why I did it

SONIC_USE_DOCKER_BUILDKIT has existed as a config variable — it's passed to the slave container (Makefile.work line 572) and printed in the build config summary (slave.mk line 428) — but was never wired up to actually set DOCKER_BUILDKIT=1. The variable is a dead config knob.

Docker BuildKit provides:

  • Parallel layer builds within each Docker image (independent RUN/COPY steps execute concurrently)
  • Better cache management with inline cache metadata
  • Improved build output with progress tracking
  • Available on Docker 18.09+ (all supported build hosts)

How I did it

  • Added the config knob documentation to rules/config (default: off/commented out)
  • Added export DOCKER_BUILDKIT := 1 in slave.mk when SONIC_USE_DOCKER_BUILDKIT=y

The change is minimal — just exporting an environment variable that Docker picks up automatically for all docker build commands.

How to verify it

# Enable in rules/config.user:
echo 'SONIC_USE_DOCKER_BUILDKIT = y' >> rules/config.user

# Build and observe BuildKit output format (shows parallel layer execution):
make configure PLATFORM=vs
make target/sonic-vs.img.gz 2>&1 | grep -i buildkit

When combined with Docker cache (SONIC_CONFIG_USE_DOCKER_CACHE), BuildKit enables inline cache metadata for efficient layer reuse across builds.

…uilds

SONIC_USE_DOCKER_BUILDKIT has existed as a config variable since it was
added, but was never wired up to actually enable BuildKit. The variable
is passed to the slave container (Makefile.work) and printed in the
build config summary (slave.mk), but DOCKER_BUILDKIT=1 is never
exported.

This change:
- Adds the config knob to rules/config (default: off)
- Exports DOCKER_BUILDKIT=1 in slave.mk when enabled

BuildKit provides:
- Parallel layer builds within each Docker image
- Better cache management
- Improved build output with progress tracking
- Available on Docker 18.09+ (all supported build hosts)

When combined with Docker cache (SONIC_CONFIG_USE_DOCKER_CACHE), BuildKit
enables inline cache metadata for efficient layer reuse across builds.

Signed-off-by: Rustiqly <[email protected]>
@rustiqly
Copy link
Contributor Author

Closing this — after digging into the history, BuildKit is already the default on all active build environments.

Full history of SONIC_USE_DOCKER_BUILDKIT:

Date PR Author What happened
Jun 2019 #3049 @stepanblyschak (Mellanox) Created — added SONIC_USE_DOCKER_BUILDKIT with proper export DOCKER_BUILDKIT=1. Noted Docker bug moby/moby#38903 (--squash + BuildKit = larger images). Default: off.
Apr 2023 #14405 @k-v1 Added explicit disableexport DOCKER_BUILDKIT=0 in else branch, because Docker 23.0 made BuildKit default and broke image sizes via the squash bug.
May 14, 2025 #19952 @sarcot (Microsoft) Removed entirely — switched to two-stage builds to work around the squash bug. Removed --squash flag and all BuildKit code. Rationale: 'BuildKit is the default now, this option will have no impact.'
May 20, 2025 #22647 @sarcot Reverted — staged builds broke something
May 28, 2025 #22733 mssonicbld Second revert
Jul 24, 2025 #23164 @sarcot Relanded — staged builds re-applied. BuildKit code removed again. But left the $(info) print line and Makefile.work passthrough as dead code.

Current state: All active build environments use Docker 24.0.2+ (bookworm/trixie slave) or Docker 29.x (host in DooD mode). Docker 23+ has BuildKit enabled by default. Nobody sets DOCKER_BUILDKIT=0 anymore. BuildKit is already active — this PR would be redundant.

The dead variable ($(info) print + Makefile.work passthrough) could be cleaned up, but that's cosmetic.

@rustiqly rustiqly closed this Feb 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant