[QGIS-Developer] Github actions analysis

[Matthias Kuhn]

According to my understanding we don't have any pressure at the moment to
move the build machines themselves, "just" to find a solution for the cache
eviction.
We could also use some cheap S3 storage as a drop in replacement with the
risk that this is not as fast as the current github cache, but this would
be easier to do than to deploy our own runners.

... however, if we want to move to self hosted runners, a few thoughts:

 - We will need multiple architectures (I assume at least windows x64,
linux x64, macos arm64)
 - We will need to install the required dependencies (build tools etc) and
manage the system images. I guess on linux that's straightforward with
docker, not sure how this should be done on other platforms (some VMs?)
 - We will need to do the required system administration and maintenance

For the vcpkg builds, I would appreciate having our own runners, as it
would make the operating system and build tool updates more predictable.
Right now, this happens every few weeks when github rolls out new runner
images. Every time this happens all dependencies are rebuilt which takes a
few hours (more than 6 hours which is the github runner limit). Such full
rebuilds could be reduced.

If we provision our own runners we should probably also get stronger ones
than the free ones from github.

Cheers
Matthias

On Tue, Oct 14, 2025 at 3:39 PM Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> (psc dropped because it will bounce)
>
> As part of this, I think it would be good to consider how things might
> be different after a move from github to either codeberg or self-hosted
> forgejo.  I don't mean to really design that, just a background thought
> of "if we (qgis.org) buy this hardware, and we later move, will we wish
> we had done something different, or will we just need more, and this
> will all be entirely usable, so it's fine".  I suspect it really is
> fine.
>
> 16 GB sounds like low RAM for a CI machine for qgis.   I would want to
> make sure it's expandable to at least 64G, and would start a bit higher.
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20251014/3096f811/attachment-0001.htm>