@TomPallister left a comment

I would suggest continuing to use the ocelot container and cake build script

First, regarding containers... The current prepared ocelot2 Docker images are simple Linux and Windows OS images with preinstalled .NET 8/9 SDKs (for .NET 9 milestone), and nothing more. The instantiated container is capable of building any .NET software, not just Ocelot. In fact, they are almost useless 😄 These containers serve as hosts in CircleCI env to run the build.cake and they act as Docker-hosted runners in the context of GitHub Actions.
Why not switch to native GitHub-hosted runners forever? To be fair, I do not want to spend my time creating Docker images with new .NET SDK versions. Also native GH-runners will allow us to improve building time.

Second, I agree to continue using build.cake, as it is the script for making releases. Note, the script must be adapted to new GH-Actions environment, because old CircleCI one required integration tokens in its variables.
Also, we need to abstract from Docker images/containers that run the script, so current GitHub-hosted runner works just fine. Another good news is the ability to run Cake scripts by GitHub action. There is a Cake-branded cake-action!

it also does the nuget publish and code coverage stuff

1. Yes, it does! I believe GitHub Actions have some built-in actions that upload .NET project packages to NuGet. However, for now, we have to make releases and upload packages using the build.cake script, which must be adapted.

2. The "Coverage stuff" is currently broken! It simply involves running the dotnet test command for the unit testing project with the special --collect:"XPlat Code Coverage" flag of the coverlet.collector library. It extracts the actual percentage coverage, but the number is not being uploaded to Coveralls due to outdated libraries related to the Cake engine. In 2024, I wrote to the repository owners and made a few contributions to the Cake.Coveralls repository. However, support is very slow, and sometimes they ignore my requests. I don't think the Coverage feature in Cake script is well-designed because of this outdated library; it will be outdated because .NET evolves quicker than this library! It would be better to migrate to a native app/action utilizing the official .NET Coveralls driver library for integrations. But you might find it a bit funny: support for this driver also seems to have stopped. The latest coveralls.net release was made almost 3 years ago and it has net6.0 TFM only. That's why I have disabled uploading to Coveralls 👉
   

   Ocelot/build.cake

   Lines 493 to 503 in ab119f8

   	Information(string.Format("Uploading test coverage to {0}", coverallsRepo));
   	// CoverallsNet(coverageSummaryFile, CoverallsNetReportType.OpenCover, new CoverallsNetSettings()
   	// {
   	// RepoToken = repoToken
   	// });
   	Warning($@"Uploading is disabled due to the following reasons:
   	- App: /root/project/tools/csmacnz.Coveralls
   	- Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
   	Upgrading csmacnz.Coveralls package to .NET 8-9 is required!!!
   	Repo: https://github.com/csmacnz/coveralls.net
   	Coveralls Language Integrations > .Net : https://docs.coveralls.io/dot-net");

I have opened PR csMACnz/coveralls.net#115 to release .NET 8-9 pack because the current TFM is net6.0 only. Unfortunately, author has not responded for two months and appears to be indifferent. The new Cake.Coveralls 4.0.0 pack may assist us as it includes net8.0 TFM. However, I currently pressed for time, and I must prioritize the release of the .NET 9 version.

@ggnaegi @RaynaldM FYI

Update 2

There are Coveralls Official Integrations.
And seems we must utilize the Coveralls GitHub Action❗