SourceHut adds continuous integration for mailing lists

SourceHut offers a continuous integration platform called builds.sr.ht, which will boot up a virtual machine from any of nine operating systems¹, including various Linux, BSD, and Plan 9 distributions, using KVM, then clone your source code repository (or repositories) and run user-defined tasks to validate the code, automate deployment, run linters, and so on. A simple example manifest from one of my projects is the following:

image: alpine/edge
sources:
- https://git.sr.ht/~sircmpwn/scdoc
tasks:
- build: |
    cd scdoc
    make    
- check: |
    cd scdoc
    make check    

For some time now, we’ve automatically submitted these build manifests on your behalf when you push to your Git or Mercurial repository. To set this up for your repos, consult the tutorial and the documentation.

SourceHut also famously endorses the email-driven workflow that git was designed for, with tools like git send-email. This allows contributors to prepare patches locally, then email them to your project’s mailing list. Now, after the introduction of the project hub, we are well positioned to connect the disparate resources of your project — repositories, mailing lists, bug trackers, and so on — to bring out more functionality, and as of this week, that includes the automated testing of patches sent to your mailing lists.

This is already working now for all projects on the project hub — to configure yours, just create a project and add both your source code repository and your mailing list to the project, and it’ll take care of the rest automatically.

There are some limitations, however:

• Patches have to have their subject prefix configured to match the name of the repository being tested. For example, “[PATCH example v2]” will be matched to a repository named “example”. Senders can configure this like so:

  git config format.subjectPrefix 'PATCH example'
  

  This is done automatically for patches submitted using the git.sr.ht patchset preparation interface. We plan on improving this later by testing the patch for applicability against each of the repositories on your project.

• Job groups remain unimplemented on builds.sr.ht, which means that projects with many build manifests may see a lot of noise from the CI.

• Mercurial repositories are not yet supported.

Leveraging the project hub to connect your resources together is something which we intend to do in a few other domains as well. For example:

• Marking patchsets as integrated when they’re applied upstream
• Linking git commits to tickets, and vice versa
• Adding the patch submitter to the build job access list so that they can SSH into failed VMs to diagnose the problem without the project admin’s intervention

And of course, this will play nicely into our plans of a more sophisticated maintainer-side workflow for handling patch submission on the web. Enjoy!