github / github/dependency-submission-toolkit

Add a field for dependency resolution errors

Offen
#78 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
TypeScript
Sterne
62
Forks
18
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

First of all, I'm sorry if this is not the right place to file this as it's more about the JSON schema for the submissions API, but I could not find a more fitting project to file this for.

Coming from [here](https://github.com/gradle/github-dependency-graph-gradle-plugin/issues/140) my ask is to add a field to the [JSON body of the submission API](https://docs.github.com/en/rest/dependency-graph/dependency-submission?apiVersion=2022-11-28#create-a-snapshot-of-dependencies-for-a-repository) that can be used to document any failures during dependency resolution.

Because currently, there seems to be no way to indicate to the API that the dependency resolution process that created the JSON might have been unable to resolve some dependencies (maybe due to temporary network issues), and thus the list of submitted dependencies might be incomplete. This is a problem if the user relies on the dependencies and resulting SBOM to be complete. On the other hand, not submitting the dependency graph at all if just a single dependency failed to resolve (maybe also due to misconfiguration on the project side) is probably not a good solution either.

So IMO the best solution is to simply be transparent and allow the dependency resolver to say so if there were any issues in dependency resolution. The GitHub web UI could then show these errors as part of the dependency graph so that he user knows to take the results "with a grain of salt".

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginne mit der im Issue verlinkten Dokumentation zum JSON-Body und zur dependency-submission API und lies anschließend das zugehörige Gradle plugin issue. Ermittle, wie Fehler bei der Auflösung von Abhängigkeiten dargestellt und gemeldet werden sollten, damit unvollständige Submissions unterscheidbar sind; die Arbeit ist abgeschlossen, wenn das Schema und das erwartete Verhalten vereinbart und dokumentiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
typescript
Bereich
api, backend-api-design
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
30/100

Neue Issues direkt in Ihr Postfach

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