Make QEMU version and flags configurable in image build Makefiles

Open Beginner friendly
#4,417 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
docker
Domain
build-system, infrastructure

Research direction

Start by comparing images/build/debian-base/Makefile, images/build/distroless-iptables/Makefile, and images/build/setcap/Makefile, focusing on QEMUVERSION, the QEMU flags in docker run, and ALL_ARCH. Check how each image build target receives variable overrides. Done means all three Makefiles allow callers to customize the QEMU version, flags, and target architectures without editing them.

Written by the indexing model from the issue text.

Description

area/release-eng kind/feature needs-priority sig/release
What would you like to be added:

In images/build/debian-base/Makefile, images/build/distroless-iptables/Makefile, and images/build/setcap/Makefile:

  1. The QEMU version (QEMUVERSION) and flags (--reset -p yes) are hardcoded
  2. The ALL_ARCH variable uses = (simple assignment) instead of ?= (conditional assignment)

This prevents downstream users and CI pipelines from customizing these values without patching the Makefiles.

Why is this needed:
  • QEMUVERSION uses = (simple assignment) instead of ?= (conditional assignment), so it cannot be overridden via environment variables
  • The QEMU flags --reset -p yes are hardcoded in the docker run command, making them impossible to override
  • ALL_ARCH uses = instead of ?=, so it cannot be overridden via environment variables
  • Making these variables conditionally assignable (?=) allows downstream consumers to customize QEMU behavior and target architectures without modifying the Makefiles
Dominant language
Go
Stars
504
Forks
556
Avg merge
18h 43m
Merged PRs (30d)
33

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from kubernetes/release

All issues in kubernetes/release

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.