lilypond-devel
[Top][All Lists]
Advanced

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

Re: testing out Docker CI scripts?


From: Han-Wen Nienhuys
Subject: Re: testing out Docker CI scripts?
Date: Sat, 22 Feb 2020 21:39:16 +0100

On Sat, Feb 22, 2020 at 3:06 PM David Kastrup <address@hidden> wrote:
> > I would be interested in your feedback.
> >
> > For example, I think it could be used for validating the staging ->
> > master push in the following way:
> >
> >  ( cd  lilypond ; git fetch origin ) && \
> > sh test-git.sh --ubuntu lilypond/  origin/staging  && \
> > sh test-git.sh --fedora lilypond/  origin/staging  && \
> >  (cd lilypond && git push origin/staging:master)
>
> That's oversimplifying the staging->master push process a bit which goes
> to considerable pain to make sure that its own copy of staging is still
> part of the upstream staging branch before pushing the tested result.
> That makes it possible to manually stop a bad staging commit from
> reaching master even if it would compile: once you reset staging, no
> already running Patchy process will override that decision with a
> version of staging that has become stale.

If there are multiple patchy processes, you'd hope they all come to
the same conclusion.

I think the code you are talking about is

  
https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test/__init__.py#L467

which doesn't look very advanced to me. You can express it as a shell script
like

  git fetch origin &&
  BEFORE=$(git rev-parse origin/staging) &&
  ( ..test as above.. ) &&
  git fetch origin &&
  test "$BEFORE" = $(git rev-parse origin/staging) &&
  git push origin origin/staging:master

> This kind of double care is tricky enough to warrant its own
> script/logic rather than rely on someone remembering all the details.

I'm not suggesting someone remembers this. Instead, we can put the
above commands in a shell script.

I want to reiterate the advantages relative to patchy:

1) we get a reproducible test process, because everyone can use the
same base images.

2) we can test against different configurations (Pango 1.44 vs. 1.36,
GUILE 1.8 vs 2.2) simultaneously, which catches problems like the
recent Pango one earlier.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen



reply via email to

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