Re: continuous integrations pipeline frameworks

Hi Simon, Thanks for your thoughts. > How do you intend the output of your python script to end up accessible > for consumption by GitLab pipelines? A simple approach is to run it > locally and commit all the generated files to git. Is that what you had > in mind? Yes, that's what I intend to

Re: continuous integrations pipeline frameworks

Bruno Haible writes: > By now, I've completed a "many platforms" CI for several GNU packages: > > https://github.com/gnu-gnulib/ci-testdir-check/actions > https://github.com/gnu-diffutils/ci-check/actions > https://github.com/gnu-gettext/ci-check/actions > https://github.com/gnu-libsigsegv/ci-che

Re: continuous integrations pipeline frameworks

Hi Eric, > Have you looked at libvirt-ci[1]? Several projects (among others: > libvirt, qemu, libnbd) use this for templating CI that works across > both gitlab and github (preferring to run CI under gitlab as it is > less invasive of freedoms, but taking advantage of github's access to > MacOS t

Re: continuous integrations pipeline frameworks

On Wed, Jul 24, 2024 at 06:23:06PM GMT, Bruno Haible wrote: > Hi Simon, > > In > you wrote: > > > And while so far I've been satisfied with writing these .yml files manually, > it would be better if they all were generated by

Re: continuous integrations pipeline frameworks

Hi Simon, In you wrote: > >> I forgot to mention: the pattern to provide re-usable GitLab CI/CD > >> definitions that I'm inspired by is Debian's pipeline project: > >> > >> https://salsa.debian.org/salsa-ci-team/pipeline/ > >

Re: continuous integrations — own runners

Bruno Haible writes: > Simon Josefsson wrote: >> I've found it to only be cost >> effective to setup my own runners for platforms that gitlab doesn't >> support natively, such as arm64 or ppc64el. > > For GitHub runners, hosting your own runners comes with security risks [1]. > > Do GitLab runner

Re: continuous integrations — own runners

Simon Josefsson wrote: > I've found it to only be cost > effective to setup my own runners for platforms that gitlab doesn't > support natively, such as arm64 or ppc64el. For GitHub runners, hosting your own runners comes with security risks [1]. Do GitLab runners have the same security risks? (I

Re: continuous integrations

Hi Simon, > Right. I also had trouble with Savannah git mirrors in the past, but > for the past year or so it has worked well. Interesting... > One of the few disadvantages with this approach that I've discovered is > that you don't get tight coupling of ci/cd script and the rest of the > repos

Re: continuous integrations pipeline frameworks

Bruno Haible writes: > Simon Josefsson wrote: >> I forgot to mention: the pattern to provide re-usable GitLab CI/CD >> definitions that I'm inspired by is Debian's pipeline project: >> >> https://salsa.debian.org/salsa-ci-team/pipeline/ >> >> It is easy to setup a new project to use their reusa

Re: continuous integrations

Bruno Haible writes: >> I think the pattern of having the .gitlab-ci.yml outside of the core >> Savannah project is a good one for those GNU projects who are not >> embracing the GitLab platform. Then GitLab-related stuff stays on the >> GitLab platform and doesn't invade the core project. > > Y

Re: continuous integrations pipeline frameworks

Simon Josefsson wrote: > I forgot to mention: the pattern to provide re-usable GitLab CI/CD > definitions that I'm inspired by is Debian's pipeline project: > > https://salsa.debian.org/salsa-ci-team/pipeline/ > > It is easy to setup a new project to use their reusable pipeline -- just > add the

Re: continuous integrations

Hi Simon, > These are useful pipelines with basic build testing! My main use of these CI pipelines are to - find regressions caused by commits in the respective packages, - find regressions caused by gnulib (despite upstream having gnulib as a git submodule), - create snapshot tarballs