Re: Cirrus CI to shut down

Alan Somers <[email protected]>
Newsgroups gmane.os.freebsd.devel.hackers
Message-ID <CAOtMX2hNLj_MCdotwCC99QZXAsAq7GBM2urWnshejPFVoOHdBw@mail.gmail.com>
On Sun, Apr 12, 2026 at 6:17 AM David Chisnall <[email protected]> wrote:
>
> On 12 Apr 2026, at 12:56, Joe Schaefer <[email protected]> wrote:
> >
> > Good points.  But I don’t mean host your own build farm. I mean use the laptop your company gave you.
>
> There are many reasons not to do this.  The top ones:
>
>  - Our builds are done in a pristine environment.  An attacker who compromises a developer’s laptop can potentially commit malicious code to the repo, but disabling force pushes means that we have an auditable view of this.  With builds done on the developers’ machine, they could just inject malicious code into the binaries.
>  - PRs from external contributors may be malicious.  Running them on a cloud VM means that they have zero access to anything we care about and the VM is destroyed at the end.  Running them on a developer machine means you’re just one container escape away from a flow from a GitHub PR to a compromised developer laptop.
>  - Developer laptops are slower than big cloud machines.
>  - Developer laptops are a single architecture, doing cross builds is annoying.
>  - Developer laptops have smaller disks, but ccache works *really* nicely if it has a lot of space to store caches for every branch.
>  - Developers often submit PRs at the end of the day and close their laptops, the cloud VM can start up when this happens.
>
> And you are talking about hosting your own build farm.  That’s the only other option.  You’re just talking about running your build farm on machines that are not always on and hold sensitive data.
>
> David

I'm considering three options to replace Cirrus:

1) https://github.com/cross-platform-actions/action .  This lets you
run FreeBSD (among other platforms) on github workflows using nested
virtualization.  That's not ideal, but at least it looks easy.  And it
doesn't solve the cost problem that David brought up.

2) https://sourcehut.org/ .  It supports CI on FreeBSD/amd64 .  The
code is open source, so a dedicated user could probably add whatever
features he needs.  Or, self-host.  However, it's still officially in
alpha, and I don't know how well it works.  And the pricing strategy
suggests that they're focused on amateurs.  Sourcehut is intended as a
full code-hosting service, but it can also be used just for CI, for
projects hosted on Github, with
https://github.com/emersion/hottub?tab=readme-ov-file .

3) Cirrus-Ci itself.  Cirrus labs claimed in their blog post that
they're going to open-source all of their code.  So anybody else could
resurrect the project.  Since Cirrus doesn't own any of its own
infrastructure, instead reusing AWS or GCE, it should be easy to
resurrect it.  Still, that's too much work for me alone.  But I might
be willing to help if somebody else takes the lead.

4) A fully personalized, serverless, cloud-hosted CI.  It seems like
it should be possible to build a personalized CI service that uses AWS
lambda functions for coordination and UI, and uses AWS or GCE virtual
machines for the CI workers.  Very scalable.  It would cost money to
use, but not very much.  This doesn't count towards my list of three
because it doesn't exist yet.  But it seems like an obvious idea.
I'll ask Santa Claus for this next Christmas.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.