@trini @deejoe I tried it a long time ago but it was pretty involved

@clacke hah. The new build server I put into service today has >2TB of disk space for the purpose of facilitating build caches in the future

@emsenn @clacke yeah, I get a lot of praise for this feature. sr.ht builds don't actually need to have a git repo at all (but they could have an hg repo as of today if you want). Here's an example:



@clacke for testing purposes you can just write a .build.yml file and drop it into builds.sr.ht/submit, by the way - no need to actually commit it to your repo. Also useful in general for testing build manifests without writing a bunch of test commits

@clacke are you an admin of that organization? It only shows repos your account is permitted to configure webhooks for. If you're able to access the webhooks page for the repo in question, it's probably a bug. Can you send me an email in that case? sir@cmpwn.com

@clacke it doesn't show forks, is this the issue?

@clacke there's first-class NixOS support but no build cache yet. I'll be working on build caching fairly soon though


@clacke if you can be convinced to move to builds.sr.ht instead of Gitlab CI that'd be swell 😉


This is a big improvement over the awful "Commons Clause" approach. It's still not open source, but this much better than pretending to be open source.

@val note: 5 minutes from when it was submitted, not from when the builder picked it up (sr.ht builders generally get started within 2-3 seconds)

@val just for fun I wrote up a build manifest for this and gave it a run, just one python version:



Took 5 mins

@val out of curiosity, what package would you be testing?

@val in parallel is not currently possible, but something I intend to work on soon.

@trini aye, that's pretty gnarly. I'd still be interested in trying to help you get it set up on builds.sr.ht, but it may require some engineering work to make it work well. Email me?

Show more

cmpwn.com is a private Mastodon instance for friends of SirCmpwn.