kernelci / kernelci/kernelci-api
[RFC] Patch building and Webhooks API
- Dominant language
- Python
- Stars
- 10
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
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)
Contributor guide
No contributing guide indexed for this repository
Research direction
No files, tests, or entry points are named. Start by reading the RFC and its unresolved Discussion questions, then map the four requested implementation areas: the Patchwork webhook, patch metadata, mbox application, and check updates. Done requires an agreed webhook contract and support for building, testing, and reporting patch results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, github, gitlab, python
- Domain
- api, backend, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100