Legacy v0 tool installer hardcodes amd64 binaries, breaking darwin/arm64 hosts

Aperta
  • Qualcosa non va?
#7,005 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@singhharsh1708 ci sta già lavorando.

Dal 6/9/2026.

  • #7006 di @rootp1 — chiusa senza merge

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, helm, kubernetes, terraform
Ambito
devops, tooling

Direzione di ricerca

Inizia da pkg/app/piped/toolregistry/tool_darwin.go e install.go, quindi confronta il templating dell’architettura in pkg/app/pipedv1/plugin/kubernetes/toolregistry/scripts.go e pkg/app/pipedv1/cmd/piped/grpcapi/tool_registry.go. Esegui i test Kubernetes mirati, inclusi helm_test.go e kustomize_test.go, e aggiungi la coverage per gli script renderizzati su un’architettura non-amd64. Il lavoro è completato quando tutti e quattro gli script di installazione legacy usano l’architettura dell’host e i test passano.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What happened:

The legacy piped v0 tool registry hardcodes amd64 in every Darwin (and Linux) install script for kubectl, kustomize, helm, and terraform. On an Apple Silicon (darwin/arm64) host, toolregistry.InitDefaultRegistry/installKubectl/installKustomize/installHelm/installTerraform in pkg/app/piped/toolregistry/tool_darwin.go unconditionally download the darwin/amd64 build of each tool, so the resulting binaries cannot execute natively on arm64 hosts.

This affects both local development and any test suite that exercises these code paths.

What you expected to happen:

The legacy v0 tool registry should resolve the host OS/architecture dynamically (the same way the newer pipedv1 tool registries already parameterize {{ .Os }} / {{ .Arch }} in their install scripts), so it downloads a binary compatible with the host architecture.

How to reproduce it:

  1. Use a darwin/arm64 machine (e.g. Apple Silicon Mac).
  2. From the repository root, run: 
    go test ./pkg/app/piped/platformprovider/kubernetes/...
  3. Observe failures such as: 
    fork/exec /tmp/piped-bin/helm: bad CPU type in executable
    in helm_test.go and kustomize_test.go, because the previously-downloaded darwin/amd64 helm/kustomize binaries cannot run on arm64.
  4. Inspect pkg/app/piped/toolregistry/tool_darwin.go (lines ~17-55) and confirm every download URL is pinned to darwin/amd64, regardless of runtime.GOARCH.

Environment:

  • piped version: repository checkout (master)
  • control-plane version: not applicable
  • Others: reproduced on macOS arm64 (Apple Silicon); confirmed via static inspection that pkg/app/piped/toolregistry/tool_darwin.go and pkg/app/piped/toolregistry/install.go never reference runtime.GOARCH, unlike the pipedv1 tool registries (e.g. pkg/app/pipedv1/plugin/kubernetes/toolregistry/scripts.go, pkg/app/pipedv1/cmd/piped/grpcapi/tool_registry.go) which already template {{ .Os }}/{{ .Arch }} from runtime.GOOS/runtime.GOARCH.

Suspected root cause:

The older v0 tool registry (pkg/app/piped/toolregistry) uses static, OS-specific install scripts written before Apple Silicon support was considered, while the pipedv1 tool registries were already generalized to resolve the host architecture at install time.

Proposed direction:

Parameterize the Darwin (and Linux) install scripts in pkg/app/piped/toolregistry with the host architecture (runtime.GOARCH), following the pattern already used by the pipedv1 tool registries, and add regression coverage asserting the rendered install scripts reference the host architecture rather than a hardcoded value.

Acceptance criteria:

  • Helm, kubectl, kustomize, and Terraform install scripts reference the host architecture instead of a hardcoded amd64.
  • The legacy (pkg/app/piped/toolregistry) and pipedv1 tool registries no longer diverge on architecture handling.
  • Focused tests cover the rendered install scripts for a non-amd64 architecture.
Lingua principale
Go
Stelle
1.4k
Fork
391
Merge medio
4g 1h
PR unite (30g)
58

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pipe-cd/pipecd

Tutte le issue di pipe-cd/pipecd

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.