lint accepts modelith-ref-type on a GitHub-origin provenance header
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 2/5
- Geschätzter Aufwand
- 1-3 Stunden
- Anfängerfreundlichkeit
- 86/100
Rechercherichtung
Beginne in internal/provenance/provenance.go bei Header.validate und lies dann den Test neben TestADR_0019_RefTypeIsRecordedOnlyWhereItIsNeeded. Reproduziere das Problem mit modelith lint beim GitHub-Ursprungs-Header und füge einen Test hinzu, der zeigt, dass modelith-ref-type für GitHub-Ursprünge einen Provenance-Befund erzeugt, während es für den dokumentierten Azure-DevOps-Fall weiterhin gültig bleibt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Follow-up from the review of #52.
ADR-0019 and docs/10-vendoring.md both say the modelith-ref-type provenance key applies only to Azure DevOps and is omitted for GitHub. Lint doesn't enforce that. Header.validate (internal/provenance/provenance.go) checks only that the value is one of branch/tag/commit, not which origin it appears on.
Repro (at 52a5544)
Take a GitHub-origin vendored copy and add the key. Here the recorded type disagrees with the ref:
# modelith-vendored: DO NOT EDIT — this file is a copy. Change it at its origin.
# modelith-fetch: git
# modelith-origin: https://github.com/acme/billing
# modelith-path: docs/payments.modelith.yaml
# modelith-ref: main
# modelith-ref-type: tag
# modelith-commit: 4f2c1e9c8b3ad0e5f71b2c9a6d4e8f30ab5c7d21
# modelith-imported: 2026-09-23
# modelith-digest: sha256:…
modelith lint gh-reftype.modelith.yaml
# 0 error(s), 0 warning(s)
deps update then drops the key without saying so (recordedRefType returns "" for GitHub).
Expected
Pre-release, the header uses closed sets (compare unknown fetch: methods), so this should be a provenance finding along the lines of ref-type is only recorded for dev.azure.com origins. Pin it with a test next to TestADR_0019_RefTypeIsRecordedOnlyWhereItIsNeeded.
- Vorherrschende Sprache
- Go
- Sterne
- 34
- Forks
- 5
- Ø Merge
- 5 Std. 7 Min.
- Gemergte PRs (30 T.)
- 6
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus stacklok/modelith
-
enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
-
documentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 92/100
-
enhancement
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 68/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 20/100
Alle Issues in stacklok/modelith
Ähnliche Issues
-
bug needs-triage
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 86/100
DataDog/dd-trace-go#5469 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug tests
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 88/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
l3montree-dev/devguard#3101 ·
Maintainer antworten meist innerhalb von 1 Tag
-
area:*of bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
oapi-codegen/oapi-codegen#2593 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
DaoCloud/DaoCloud-docs#7432 ·
Maintainer antworten meist innerhalb von 1 Tag