Re: Cirrus CI to shut down

On Sun, Apr 12, 2026 at 10:52 AM Moin Rahman <[email protected]> wrote:
>
>
>
> > On Apr 12, 2026, at 18:41, Alan Somers <[email protected]> wrote:
> >
> > 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.
> >
>
> I think Option 3 is not correct. They are going opensource only for
> some of their products which includes Tart, Vetu and Orchard.
>
> I am working with one of my ex-client about something that I built
> for them ages ago if we can goopensource. I will keep this list posted.
>
> Kind regards,
> Moin

I just learned about an additional option.  BuildKite has native
support for FreeBSD.  There's a devel/buildkite-agent port that can be
used for self-hosted CI workers, paired with BuildKite's cloud-based
orchestration.  There's also the Elastic CI stack, which spins up
cloud-based workers on demand.  The docs only mention Linux and
Windows, but a BuildKite support engineer assured me that it will work
for FreeBSD too.  This option would no doubt have better performance
than the nested-virtualization stuff.  And probably better pricing
too.  But damn if it isn't intimidating to get started.  Maybe
CheriBSD could use it, but I fear that it's beyond the reach of a
hobbyist.

https://buildkite.com/docs/agent/self-hosted/aws/elastic-ci-stack
https://buildkite.com/docs/agent/self-hosted/gcp/elastic-ci-stack