Re: Granular building

[Michael Albinus]

Psionic K <psionik@positron.solutions> writes:

Hi,

> I was just curiously looking around and saw in a thread:
>
>> It seems that emba.gnu.org suffers from severe overload
>
> https://lists.gnu.org/archive/html/emacs-build-automation/2022-12/msg00000.html

Thanks for joining the discussions!

> I have worked on some granular caching of build outputs in Nix.  Since
> it's pure, the result is mostly referentially transparent with the
> cache, which allows skipping work.  (There is known impurity remaining
> in Emacs and Guix)
>
> The catch is that the work has to be isolated into several independent
> derivations for any useful caching to occur.
>
> How apt is the Emacs build to being broken up and where are the
> obvious boundaries  that would cut down build time?

On emba.gnu.org, we use a Gitlab instance for CI/CD tests. See
<https://emba.gnu.org/emacs/emacs/-/pipelines> how it looks like.

The split into different test jobs is described by the files in the
Emacs git repository, directory test/infra/. The dependencies between
different jobs are described her, and the results for reuse are kept as
docker containers.

If you are familiar with Gitlab, you might inspect this workflow. Don't
hesitate to ask if you don't understand. (However, I won't be able to
give a Gitlab CI/CD introduction if needed)

Best regards, Michael.