Re: Using gitlab-ci to maintain a channel?
Hi Ludo, thanks for the answer. Looks like I need to go with Cuirass. But more probably I'll abandon the idea for now since its a spare-time project only. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Using gitlab-ci to maintain a channel?
Hi Hartmut! Hartmut Goebel skribis: > I wonder whether it's possible to maintain a channel using gitlab-ci. Any > thought or experiences to share? [...] > * What version of guix shall be used? Always the latest one? That’s the main conceptual issue: GitLab-CI only knows about the repo it’s tracking, it doesn’t realize that whether the code therein builds fine depends on the ‘guix’ channel. To get that level of precision, you would need Cuirass, which is what we use at work and for various scientific channels: <https://guix.bordeaux.inria.fr>. Now, GitLab integration is appealing, so it would still be nice to do CI with a fixed revision of Guix, which you would occasionally manually update. It’s a tradeoff. > * The runners need a docker image. Where to I get one? Possibly containing a > warmed-up cache? (Using a Debian docker image and > installing guix into it on every run sounds like a bad idea.) As I mentioned on help-guix a few days (weeks?) ago, I haven’t found a way to build such an image with Guix, but I’d like to find one! Another option is to use, say, Debian as the base image, and to install Guix on top of it. > * OTOH /gnu/tore could be cached. How much data would this typically be? > * How to clean the cache from unreachable items? > * How to publish the substitutes? I don’t think you could publish substitutes in that setup, unless GitLab-CI offload builds to an actual machine that has ‘guix publish’ running on it. HTH, Ludo’.
Using gitlab-ci to maintain a channel?
Hi, I wonder whether it's possible to maintain a channel using gitlab-ci. Any thought or experiences to share? My idea is to schedule jobs which are refreshing the packages, building/testing them and to provide substitutes. The channel is meant for Tryton (tryton.org), which consists of about 200 plug-in packages and bug-fixes are published for the LTS version every now and then. The channel should follow these bug-fix releases. Tryton is pure Python, anyhow some dependencies require C, C++ and even rust for building, updating dependencies should be avoided if not all substitutes for all dependencies are available (or maybe deny-list specific dependencies). The points I'm wondering are: What version of guix shall be used? Always the latest one? The runners need a docker image. Where to I get one? Possibly containing a warmed-up cache? (Using a Debian docker image and installing guix into it on every run sounds like a bad idea.) OTOH /gnu/tore could be cached. How much data would this typically be? How to clean the cache from unreachable items? How to publish the substitutes? Why gitlab-ci? Well, the channel will live on a gitlab instance, thus using that infrastructure would simplify things and avoid single users managing processes. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
