docker / docker/github-builder

Provenance issue with public repository

Offen
#193 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

status/triage
Vorherrschende Sprache
Keine Sprachdaten
Sterne
83
Forks
23
Ø Merge
2 T. 22 Std.
Gemergte PRs (30 T.)
8

Beschreibung

Contributing guidelines
I've found a bug, and:
  • The documentation does not mention anything about my problem
  • There are no open or closed issues that are related to my problem
Description

Hello,

My repository is public (https://github.com/nsphung/mcp-snowflake-server/blob/main/Dockerfile). And from my understanding, using docker/github-builder (docker/github-builder/.github/workflows/build.yml@7d2a02426d4b989616ba5aaee4e879afd4134b0d # v1.6.0), it should use docker/buildx provenance = mode=max,version=v1. But I don't have the expected results.

Expected behaviour

This is what I have without using docker/github-builder:

docker buildx imagetools inspect nsphung/mcp-snowflake-server-nsp:0.8.0 --format "{{ json .Provenance.SLSA }}"
# This one is working

This was build with:

docker buildx build \                                                     
    --tag nsphung/mcp-snowflake-server-nsp:0.8.0 \      
    --sbom=true \                 
    --attest type=provenance,mode=max,version=v1 \
    .

Is there any way to have the same feature in docker/github-builder ? Or maybe I'm missing a configuration.

Actual behaviour
docker buildx imagetools inspect nsphung/mcp-snowflake-server-nsp:0.11.2 --format "{{ json .Provenance.SLSA }}"
null%                                                          

Here we can see null when inspecting for provenance.

Repository URL

https://github.com/nsphung/mcp-snowflake-server/tree/main

Workflow run URL

https://github.com/nsphung/mcp-snowflake-server/actions/runs/25457043001

YAML workflow
You can checkout the yaml at:

https://github.com/nsphung/mcp-snowflake-server/blob/main/.github/workflows/publish.yml#L176
Workflow logs

No response

BuildKit logs

Additional info

No response

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Öffne einen Pull Request, der die Issue-Nummer nennt.

Rechercherichtung

Beginne mit .github/workflows/publish.yml ungefähr in Zeile 176 und der bei v1.6.0 festgelegten .github/workflows/build.yml und vergleiche anschließend deren Build-Konfiguration mit dem funktionierenden docker buildx-Befehl. Reproduziere den Workflow und untersuche das resultierende Image mit docker buildx imagetools; das Issue ist abgeschlossen, wenn die unterstützte Konfiguration oder Einschränkung festgestellt und das Verhalten bezüglich der Provenance dokumentiert oder korrigiert wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
docker, github-actions
Bereich
ci-cd, devops, security
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
45/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.