On Sat, Feb 8, 2020 at 11:31 PM Janek Warchoł
wrote:
> In principle, thumbs up. However, I think it's essential that we don't try
> to do too much at once; I'd suggest to focus on one most important aspect
> first. To do that, I'd like to ask a helper question: what are 2 most
> important reasons
sob., 8 lut 2020 o 23:30 Janek Warchoł
napisał(a):
> In principle, thumbs up. However, I think it's essential that we don't try
> to do too much at once; I'd suggest to focus on one most important aspect
> first. To do that, I'd like to ask a helper question: what are 2 most
> important reasons f
In principle, thumbs up. However, I think it's essential that we don't try
to do too much at once; I'd suggest to focus on one most important aspect
first. To do that, I'd like to ask a helper question: what are 2 most
important reasons for using Docker instead of Patchy? In other words, what
are 2
On Sat, Feb 8, 2020 at 7:24 PM Jonas Hahnfeld wrote:
> > the point is that you can take a snapshot of the full build at a point
> in time. As long as the C++ code doesn't change dramatically between that
> point and the commit to be tested, you'd get cache hits on a "clean" build
> at a new comm
Am Samstag, den 08.02.2020, 19:18 +0100 schrieb Han-Wen Nienhuys:
>
>
> On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld wrote:
> > > > * if instead we build images for every commit, then incremental
> > > > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > > > any header fi
On Fri, Feb 7, 2020 at 9:48 PM Dan Eble wrote:
> On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote:
> >>> * use a headless browser to take a image snapshot of the top of
> regtest
> >>> result page.
> >>>
> >> Sounds convoluted. Why not attach the difference images directly?
> >
> > Those are
On Sat, Feb 8, 2020 at 2:05 PM Jonas Hahnfeld wrote:
>
> > > * if instead we build images for every commit, then incremental
> > > building of a provided patch will be fast(er) (_if_ it doesn't touch
> > > any header file). But what's then the point of using ccache, we can
> > > just trigger a f
Am Samstag, den 08.02.2020, 13:51 +0100 schrieb David Kastrup:
> Jonas Hahnfeld via Discussions on LilyPond development
> <
> lilypond-devel@gnu.org
> > writes:
>
> > Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> > > Considerations
> > > ==
> > >
> > > * Because
Jonas Hahnfeld via Discussions on LilyPond development
writes:
> Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
>>
>> Considerations
>> ==
>>
>> * Because the build happens inside a container, we can test multiple
>> builds. We could build against guile 1.8 and
Am Freitag, den 07.02.2020, 13:21 +0100 schrieb Han-Wen Nienhuys:
> Proposal: rather than using the patchy scripts for validating
> LilyPond, we use docker images.
>
> General idea
>
>
> There is a script ("driver") that drives docker running on a dedicated
> build machine ("host").
> * Because the build happens inside a container, we can test multiple
> builds. We could build against guile 1.8 and 2.2 at the same time,
> for example.
I have zero experience with docker, but your suggestions sound quite
interesting!
Regarding image comparison: The Chromium team uses Free
On Feb 7, 2020, at 16:23, Han-Wen Nienhuys wrote:
>
> More work , and I'm lazy :)
No problem! Jonas is probably bored now that there's nothing left to port to
Python 3.
—
Dan
I aim to communicate with empathy. Have I failed? ¯\_(ツ)_/¯
On Fri, Feb 7, 2020 at 9:48 PM Dan Eble wrote:
> On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote:
> >>> * use a headless browser to take a image snapshot of the top of
> regtest
> >>> result page.
> >>>
> >> Sounds convoluted. Why not attach the difference images directly?
> >
> > Those are
On Feb 7, 2020, at 15:22, Kevin Barry wrote:
> P.S. I think I have seen a dockerfile for creating a build environment
> for LilyPond somewhere.
https://github.com/fedelibre/LilyDev/tree/master/docker
I'm using it. I'm not sure who else is.
—
Dan
On Feb 7, 2020, at 15:21, Han-Wen Nienhuys wrote:
>>> * use a headless browser to take a image snapshot of the top of regtest
>>> result page.
>>>
>> Sounds convoluted. Why not attach the difference images directly?
>
> Those are potentially 1372 images to attach if you made a change with g
On Fri, Feb 7, 2020 at 8:55 PM Dan Eble wrote:
> On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
> >
> > * runs (make ; make test-baseline)
>
> If this says "(make ;" because you think that "make test-baseline"
> requires a prior make, I think it is incorrect. (If "make test-baseline"
> does
On Fri, Feb 07, 2020 at 01:21:35PM +0100, Han-Wen Nienhuys wrote:
> Proposal: rather than using the patchy scripts for validating
> LilyPond, we use docker images.
Without getting into technical details, I think this is a really good
idea. Automatic building/testing saves lots of time, and having a
On Fri, Feb 7, 2020 at 9:12 PM Dan Eble wrote:
> On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
> > * use a headless browser to take a image snapshot of the top of regtest
> > result page.
>
> Sounds convoluted. Why not attach the difference images directly?
>
Those are potentially 1372 im
On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
> * use a headless browser to take a image snapshot of the top of regtest
> result page.
Sounds convoluted. Why not attach the difference images directly?
> On success, the driver uploads the image snapshot to code review.
>
> On failure, the
On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
>
> * runs (make ; make test-baseline)
If this says "(make ;" because you think that "make test-baseline" requires a
prior make, I think it is incorrect. (If "make test-baseline" doesn't work on
its own, it should be fixed.)
If this says "(m
On Feb 7, 2020, at 07:21, Han-Wen Nienhuys wrote:
>
> contains a copy of ccache
ccache is interesting. It speeds up recompiling files after a make clean,
which is great if you often have to make clean because your makefile is broken,
or if you often reconfigure your build options (e.g. debug
Proposal: rather than using the patchy scripts for validating
LilyPond, we use docker images.
General idea
There is a script ("driver") that drives docker running on a dedicated
build machine ("host").
There are several images:
* The base dev image.
The base image is based on some
22 matches
Mail list logo
