Han-Wen Nienhuys <hanw...@gmail.com> writes: > Hi there, > > I've been working on a set of scripts that provides a reproducible > test environment for running LilyPond regtests. In addition to being > reproducible, it has some performance tweaks to speed up > recompilations.
Performance tends to be part of what we end up looking at. Not as a regular thing, but it does tend to get obvious eventually when there is a regression. So we should make this more formal. > See https://github.com/hanwen/lilypond-ci > > 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. This kind of double care is tricky enough to warrant its own script/logic rather than rely on someone remembering all the details. -- David Kastrup
