[Vm-dev] hiearchy of build stages

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Apr 2 16:21:15 UTC 2018


Hi Fabio,
I have already edited the build stages of .tavis.yml
I'll publish this evening.
Maybe you will want to review?

Doesn't macos build start in parallelel of inux ones?

2018-04-02 18:05 GMT+02:00 Fabio Niephaus <lists at fniephaus.com>:

>
> Hi all,
>
> On Mon, Apr 2, 2018 at 3:36 PM Nicolas Cellier <nicolas.cellier.aka.nice@
> gmail.com> wrote:
>
>>
>> Agree,
>> you see, now it's win32 pharo.cog.spur.lowcode which triggers the gcc
>> error
>> https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1209
>>
>> It's like I will need the whole day with error/retry to make some green
>> status back (or it's presomptuous).
>>
>> 2018-04-02 15:29 GMT+02:00 Alistair Grant <akgrant0710 at gmail.com>:
>>
>>>
>>> Hi Nicolas,
>>>
>>> Good idea.  If the build order can't be controlled...  I thought
>>> newspeak builds had been tagged so that they didn't cause the whole
>>> job to fail.  Maybe sista, lowcode and v3 builds could be marked the
>>> same?
>>>
>>
> At the moment, no builds are allowed to fail. But I'd agree that it make
> sense to flag experimental builds as such.
>
>
>>
>>> Cheers,
>>> Alistair
>>>
>>>
>>> On 2 April 2018 at 15:25, Nicolas Cellier
>>> <nicolas.cellier.aka.nice at gmail.com> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > there are lot of jobs at each opensmalltalk-vm commit like
>>> > https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/builds/361159455
>>> >
>>> > some of these jobs are of vital importance beacuse candidates for
>>> production, some have less because rather experimental (sista lowcode) or
>>> backward compatibility (v3).
>>>
>> >
>>> > If ever it's technically possible, which I didn't check, could we
>>> agree at least on the order of build stages so that we build candidates for
>>> production first and at least know if commits have an impact on these?
>>> > Currently, a single failure of experimental brand will cut the whole
>>> feedback.
>>>
>>
> We can, of course, re-organize build stages at any time. When I introduced
> build stages, I just wanted to have Linux builds first because Travis'
> macOS environments are slower (they still are, but Travis has significantly
> improved the situation in the meantime).
> It makes sense to split builds into two the groups, stable and
> experimental. However, I'm not sure if we want to keep grouping by
> architecture at the same time because then we'd have 8 instead of 4 build
> stages. Maybe we just need to split the Linux and macOS build stages into
> Linux/macOS x Stable/Experimental and leave everything else as is?
>
> Fabio
>
>
>
>> >
>>> > It's more a temporary workaround than a long term solution, but let's
>>> make small steps, or we'll never see any progress.
>>> >
>>> > Nicolas
>>> >
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180402/b1d19ea6/attachment.html>


More information about the Vm-dev mailing list