[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orchestration][RFC] A simple draft for channels
From: |
myglc2 |
Subject: |
Re: [Orchestration][RFC] A simple draft for channels |
Date: |
Mon, 19 Mar 2018 14:21:35 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hi Pjotr,
On 03/19/2018 at 13:04 Pjotr Prins writes:
> Let's start up again on this conversation in the context of
> deployment. I have a simple use case. For GeneNetwork we maintain
> GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
> main line (such as python-gunicorn), but also packages that will never
> make it (such as a javascript twitter feed).
>
> Now we deploy multiple setups, which I'll simplify to development,
> testing and production here (there are more!). Each of these has a
> combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.
>
> These git repo's are supposedly in sync with each other.
>
> Moving from one to the other, however, is too complicated and error
> prone. I can do it, but no one else really wants to. Even with my
> explanations it proves to be a royal pain.
How about making guix a submodule of the GeneNetwork repo?
> Now I need a way to no longer rebuild all .go files for Guix tree
> updates/changes. Not only between switching branches, but also when
> just running 'git pull' from Guix savannah. I find I have to do that
> very often. So often that I don't even try running make anymore
> without make clean. Anyone here share that experience?
Yes the guix make does seem rather fragile ;-) So I usually do ...
guix environment guix -M 4 -c 4 --ad-hoc help2man git strace
rm -fr /home/g1/.cache/guile/ccache/*
sudo git clean -dfx
git pull
./bootstrap
./configure --localstatedir=/var --sysconfdir=/etc
make -j 10
make -j 10 check
This takes a while but it avoids me chasing spurious errors caused by
clashes between the state of my build directory and the upstream
changes ;-)
> One thing I could do is split out 3 git repos for every use case and
> update these individually not triggering rebuilds. And when I deploy
> on other machines move the complete repo across with .go files.
Have you considered a git-worktree for each of the development, testing
and production branches?
HTH - George