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
21 matches
Mail list logo
