Kaniko + Azure DevOps: Clone First, Build Second

Kaniko can fail against Azure DevOps Git URLs because the underlying git client does not support the required multi-ack negotiation path.

💡The Lesson

If your image build flow relies on Kaniko cloning source directly from Azure DevOps, build failures can happen before Dockerfile execution even starts. The issue is not your auth token or repository permissions; it is protocol capability mismatch in the clone layer.

🚫What Doesn't Work

Retrying with new PATs: Auth rotates cleanly, but clone still fails.
Tweaking Kaniko flags: Push/cache flags do not change Git protocol support.
Assuming broken repo ACLs: Permissions may be correct while clone negotiation still breaks.

✅The Solution

Clone in an initContainer: Use a full Git client (for example system Git) to checkout the repository into a shared volume.
Feed Kaniko a local workspace: Point--context to the mounted path instead of a remote Git URL.
Keep responsibility split: InitContainer handles source retrieval; Kaniko handles image build and push only.

ℹ️

This pattern aligns well with operators: source acquisition becomes a deterministic step, and Kaniko receives a stable local context every time.

📚Context

Environment: K3s operator launches ImageBuild pods.
Observed behavior: Remote Azure DevOps Git context fails; local checked-out context succeeds.
Takeaway: Treat Kaniko as a builder, not as a universal Git transport layer.

References: