Title: About pipelining OpenBSD ports contributions | |
Author: Solène | |
Date: 27 September 2020 | |
Tags: openbsd automation | |
Description: | |
After modest contributions to the NixOS operating system which made | |
me learn about the contribution process, I found enjoyable to have | |
an automatic report and feedback about the quality of the submitted | |
work. While on NixOS this requires GitHub, I think this could be | |
applied as well on OpenBSD and the mailing list contributing system. | |
I made a prototype before starting the real work and actually I'm | |
happy with the result. | |
This is what I get after feeding the script with a mail containing | |
a patch: | |
Determining package path ✓ | |
Verifying patch isn't committed ✓ | |
Applying the patch ✓ | |
Fetching distfiles ✓ | |
Distfile checksum ✓ | |
Applying ports patches ✓ | |
Extracting sources ✓ | |
Building result ✓ | |
It requires a lot of checks to find a patch in the file, because | |
we have have patches generated from cvs or git which have a slightly | |
different output. And then, we need to find from where to apply | |
this patch. | |
The idea would be to retrieve mails sent to [email protected] by | |
subscribing, then store metadata about that submission into a | |
database: | |
Sender | |
Date | |
Diff (raw text) | |
Status (already committed, doesn't apply, apply, compile) | |
Then, another program will pick a diff from the database, prepare a VM | |
using a | |
derivated qcow2 disk from a base image so it always start fresh and | |
clean and ready, and do the checks within the VM. | |
Once it is finished, a mail could be sent as a reply to the original | |
mail to give the status of each step until error or last check. The | |
database could be reused to make a web page to track what compiles | |
but is not yet committed. As it's possible to verify if a patch is | |
committed in the tree, this can automatically prune committed patches | |
over time. | |
I really think this can improve tracking patches sent to ports@ and | |
ease the contribution process. | |
**DISCLAIMER** | |
- This would not be an official part of the project, I do it on my own | |
- This may be cancelled | |
- This may be a bad idea | |
- This could be used "as a service" instead of pulling automatically | |
from ports, meaning people could send mails to it to receive an | |
automatic review. Ideally this should be done in portcheck(1) but | |
I'm not sure how to verify a diff apply on the ports tree without | |
enforcing requirements | |
- **Human work will still be required to check the content and verify | |
the port works correctly!** |