This message is to put colleagues from KM3NeT project in contact with people on this forum in an attempt to provide them with advice on how to establish a procedure in their Gitlab repository, allowing the software continuous integration (CI) chain to end with an upload to CVMFS.
Currently the /cvmfs/km3net.egi.eu repo is hosted by the Stratum-0 at STFC RAL (part of the EGI Software Distribution service) and the uploading and maintaining operations of the repository involve manual interventions (cf. https://docs.egi.eu/users/compute/software-distribution/#distributing-new-content), so we wonder whether a better approach could exist i.e. a programmatic way to upload files to CVMFS from CI pipelines?
we have some user groups at us who are using their CVMFS repositories for publishing their software/containers. Our approach is using plain gitlab runners on the groups’ stratum-0 release server. I.e., not much of a very fancy set up, but installing the shell gitlab runner, setting it up under the functional user/creating a dedicated pipeline runner token in Gitlab, and attaching the runner to their CI/CD pipeline. The groups have somewhat of a multi-runner set up with another runner doing the build stuff on their build instances and then as a final publishing stage the CVMFS runner on the stratum-0 checking out the release and copying it into a commit.
If you have questions, please ping me for a chat or so (but in the end it is not very much of an elaborate set up tbh)
so in general current model for publishing to CVMFS is very straightforward - a dedicated publisher machine has write access to the repository. It allows to be very flexible in how files are published to /cvmfs. There are many different approaches to publishing and there are a lot of programmatic CI pipelines that are used to publish. I’m aware of repositories that publish strictly with manual intervention, others that use Jenkins, cron jobs, Github Actions and indeed Gitlab CI.
Since most build systems are different, there’s not one perfect solution here unfortunately. The problem tends to be how the relocation is handled - if RPATHS need to change, strings need to be replaced …
So I think there is nothing stopping you from setting up the publisher machine as a gitlab runner, or giving the build machine access to a secret with its ssh key and defining the workflow. If you have access, here some colleagues from CERN documented how they recently did the same thing: https://its.cern.ch/jira/browse/SPI-2940 ( if you don’t I can send you the content of the ticket in private message ).
There may also be others who can share their experience (as Thomas already did, thanks!) If you have time, the next coordination meeting would be a good place to discuss: CernVM-FS Coordination Meeting (9 February 2026) · Indico
Lastly, we do have an item in the program of work of this year to make publishing from build machines easier (bringing together some exisiting ideas like the ephemeral publish shell and the conveyor infrastructure). That will take some time (likely a couple of months) to implement though. But it’s great to already collect feedback how publishing could be improved.