Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[RFC] Patch building and Webhooks API

Offen
  • Stimmt etwas nicht?
#307 22 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

@yurinnick arbeitet bereits daran.

Seit 01.8.2023.

  • #295 von @yurinnick — ohne Merge geschlossen
  • #297 von @yurinnick — offen
  • #299 von @yurinnick — offen
  • #2041 von @yurinnick — ohne Merge geschlossen

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
git, github, gitlab, python
Bereich
api, backend, backend-api-design

Rechercherichtung

Es werden keine Dateien, Tests oder Einstiegspunkte genannt. Beginne damit, den RFC und seine offenen Discussion-Fragen zu lesen, und ordne dann die vier angeforderten Implementierungsbereiche zu: den Patchwork-Webhook, Patch-Metadaten, die mbox-Anwendung und Check-Aktualisierungen. Als abgeschlossen gilt die Arbeit, wenn ein abgestimmter Webhook-Vertrag sowie Unterstützung für das Erstellen, Testen und Melden von Patch-Ergebnissen vorhanden sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Webhook API should help to integrate KernelCI with patch management (Patchwork) and version control systems (Github, Gitlab). It will provide interface to trigger non-upstream patch builds that should be able to publish results back later.

Implementation

As the first step, I'd like to implement Patchwork integration with KernelCI. Following changes should be implemented:

  1. Add /webhooks/patchwork API that will expect certain (TBD) input from Patchwork side, enough to build and test kernel, and report back results
  2. Extend kernelci.Node, KernelBuildMetadata, kernelci.config.Tree with patch-related fields
  3. Implement patch mbox application on top of git checkout
  4. Implement Patchwork patch checks update mechanism

Minimal patch information

We need a patch and all dependent patches information, as well as submitter information for email notifications.

{
  "patches": [
    {
      "patchwork_id": "str",
      "hash": "str",
      "web_url": "str",
      "date": "str",
      "mbox": "str"
    }
  ],
  "submitter": { 
    "id": "int", 
    "url": "str", 
    "name": "str", 
    "email": "str" 
  }
}

Discussion

  • How to make patches information generic enough to share across multiple systems? Should we make it generic at all?
  • How to pass Patchwork specific metadata into Node? data field or a separate field?
  • Calculating and passing revision information
  • What data should we expect in /webhooks/patchwork? (Collaboration with Patchwork developers)
Vorherrschende Sprache
Python
Sterne
10
Forks
21
Ø Merge
22 Min.
Gemergte PRs (30 T.)
1

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus kernelci/kernelci-api

Alle Issues in kernelci/kernelci-api

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

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