<div dir="auto"><div dir="ltr">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.<div>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.</div><div><div><br></div><div>... however, if we want to move to self hosted runners, a few thoughts:</div><div><br></div><div> - We will need multiple architectures (I assume at least windows x64, linux x64, macos arm64)</div><div> - 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?)</div><div> - We will need to do the required system administration and maintenance</div><div><br></div><div>For the vcpkg builds, I would appreciate having our own runners, as it would make the operating system and build tool updates more predictable.</div><div>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.</div></div><div dir="auto"><br></div><div dir="auto">If we provision our own runners we should probably also get stronger ones than the free ones from github.</div><div><br></div><div dir="auto">Cheers</div><div dir="auto">Matthias</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 14, 2025 at 3:39 PM Greg Troxel via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank" rel="noreferrer">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(psc dropped because it will bounce)<br>
<br>
As part of this, I think it would be good to consider how things might<br>
be different after a move from github to either codeberg or self-hosted<br>
forgejo.  I don't mean to really design that, just a background thought<br>
of "if we (<a href="http://qgis.org" rel="noreferrer noreferrer" target="_blank">qgis.org</a>) buy this hardware, and we later move, will we wish<br>
we had done something different, or will we just need more, and this<br>
will all be entirely usable, so it's fine".  I suspect it really is<br>
fine.<br>
<br>
16 GB sounds like low RAM for a CI machine for qgis.   I would want to<br>
make sure it's expandable to at least 64G, and would start a bit higher.<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>