unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mathieu Othacehe <othacehe@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: The Guix Build Coordinator in 2021
Date: Wed, 10 Feb 2021 11:58:13 +0100	[thread overview]
Message-ID: <87sg642nqy.fsf@gnu.org> (raw)
In-Reply-To: <878s7xx9tx.fsf@cbaines.net> (Christopher Baines's message of "Tue, 09 Feb 2021 20:30:51 +0000")


Hello Chris,

> Near the beginning of 2020, things changed such that I suddenly had some
> time, and some of that time I spend putting idea's I'd had for a while
> around building derivations, including across multiple machines, in to
> practice [1].

With the Guix Build Coordinator, you made an impressive work, probably
based on the observation that the "guix-daemon" and its offloading
mechanism was too limited.

We are now in a situation where our continuous integration system,
while performing better and better is getting out of hand. Here are the
different software I'm keeping track of:

* Cuirass, deployed on ci.guix.gnu.org
* The Guix Build Coordinator, deployed on guix.cbaines.net
* The Guix Data Service, deployed on data.guix.gnu.org
* Patchwork, deployed on patchwork.cbaines.net

All those services have databases, using different DBMS on different
servers. Those databases are sometimes overlapping, in the same way as
some of the features of those software.

In particular I feel that what's implemented in the Guix Build
Coordinator can be seen as a subset of Cuirass functionalities. As you
know, I'm reluctant to the idea of connecting Cuirass to the Guix Build
Coordinator, because most of Cuirass PostgreSQL database content would
be duplicated in the SQLite database of the GBC.

On the other hand, maintaining those two software in separate ways seems
like a huge waste of time given the very limited number of people
contributing the maintenance of the CI system.

Furthermore, some of the features we are implementing here, should be
part of the "guix-daemon" itself, which makes me think that we should
not place too much effort in their development.

My proposition would be to make a listing of both Cuirass and the GBC
features, and see how we could merge them. By maintaining a single
software, with a single database, running on the same server, we could
spare some efforts, and quickly converge towards a better CI.

The new Cuirass architecture and the switch to PostgreSQL, make the
software way more modular, and should allow us to add new
functionalities without too much trouble.

What do you think of that proposition?

Thanks,

Mathieu


  reply	other threads:[~2021-02-10 10:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 20:30 The Guix Build Coordinator in 2021 Christopher Baines
2021-02-10 10:58 ` Mathieu Othacehe [this message]
2021-02-10 20:07   ` Christopher Baines
2021-02-10 22:29   ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sg642nqy.fsf@gnu.org \
    --to=othacehe@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).