Skip to content

fix: extract debug file from same image to ensure matching BuildID#8399

Draft
rubenfiszel wants to merge 4 commits intomainfrom
worker-stuck-cpu-slow-queries
Draft

fix: extract debug file from same image to ensure matching BuildID#8399
rubenfiszel wants to merge 4 commits intomainfrom
worker-stuck-cpu-slow-queries

Conversation

@rubenfiszel
Copy link
Copy Markdown
Contributor

Summary

Follow-up to #8396. The separate depot --target debuginfo build produced a binary with a different BuildID than the shipped binary. This simplifies the approach: extract the .debug file from the same EE image as the binary.

Changes

  • Dockerfile: Remove the debuginfo scratch stage. Copy .debug file to the final image alongside the binary.
  • CI workflow: Remove the separate attach_ee_debug_to_release job (saved depot compute). Extract .debug from the same EE image using shrink/actions-docker-extract in the existing attach_amd64_binary_to_release job.

Trade-off

Docker image is ~1.5GB larger due to the .debug file. The file doesn't affect runtime — it sits on disk unused unless you need to debug. The alternative (separate build) wastes CI compute and produces mismatched BuildIDs.

Test plan

  • CI extracts windmill-ee-amd64.debug from the same image as windmill-ee-amd64
  • BuildIDs match between binary and debug file
  • gdb -ex "symbol-file windmill.debug" -ex "bt" -p 1 resolves source file:line

Generated with Claude Code

rubenfiszel and others added 3 commits March 16, 2026 15:18
Generate line-table debug info in release builds and split it into
a separate .debug file. The shipped binary remains stripped (same
size as before), while the .debug files are attached to GitHub
releases for both amd64 and arm64 EE builds.

This enables production debugging with gdb/perf by copying the
matching .debug file into a running pod.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Use a `FROM scratch AS debuginfo` stage instead of copying the .debug
file to the final image. This keeps the shipped image at exactly the
same size as before. CI extracts the .debug file using depot's
--target debuginfo with cache hits from the main build.

Also adds gnu_debuglink so gdb auto-discovers the debug file when
placed next to the binary.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The separate depot build for --target debuginfo produced a binary with
a different BuildID than the shipped binary. Extract the .debug file
from the same EE image instead — no extra CI build, guaranteed match.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@cloudflare-workers-and-pages
Copy link
Copy Markdown

cloudflare-workers-and-pages bot commented Mar 16, 2026

Deploying windmill with  Cloudflare Pages  Cloudflare Pages

Latest commit: 44e316a
Status: ✅  Deploy successful!
Preview URL: https://728c51bf.windmill.pages.dev
Branch Preview URL: https://worker-stuck-cpu-slow-querie.windmill.pages.dev

View logs

Move the debuginfo extraction into the build_ee job, right after the
main build+push. Since it runs on the same depot runner with a warm
cache, the --target debuginfo step should be a cache hit (no recompile).
The separate attach_ee_debug_to_release job caused a full recompile
on v1.658.0 (~16 min per platform).

The .debug file stays out of the final image (zero image size increase).

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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