guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Guix and Continuous Integration (CI)


From: Christopher Baines
Subject: Guix and Continuous Integration (CI)
Date: Fri, 01 Feb 2019 18:05:04 +0100
User-agent: mu4e 1.0; emacs 26.1

So, it might be good to have a discussion about "continuous
integration", what this means, and how it applies to Guix.

I believe the term comes from the field of software development, as a
practice, it has multiple components, but I think the most significant
one comes from the name. When practising continuous integration with
software, you should continuously integrate your changes (patches),
normally this means you promptly merge all the different changes
together in your version control system.

This practice is utilised for a large proportion of changes to Guix,
they are merged to the master branch. However, the way the staging and
core-updates branches are used is an example of not following
"continuous integration". Changes can wait for a while before being
merged in to the master branch.

It seems to me that continuous integration is a related concept, but
separate to the building things (packages/system tests/...). When
thinking about continuous integration, it might be good to think about
what the ideal workflow would be for Guix changes, assuming for a moment
that the "building things" situation was perfect.

Currently, changes are held in core-updates and staging so that
substitutes can be built, but if you can build substitutes as fast as
you want, I think there would still be advantages for batching the
changes. Imagine if the changes that would go in to core-updates go in
to master, even if there are substitutes are available, it could result
in Guix users having to download large amounts of substitutes, and
depending on the change, some proportion of these changes may be
redundant as the change to the derivation wouldn't have altered the
behaviour of the software.

Therefore, for changes that affect a large number of derivations without
much functional impact on most of those affected derivations, it would
reduce the impact to batch those changes somewhat.

Anyway, there are some thoughts,

Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]