[Vm-dev] hiearchy of build stages

Fabio Niephaus lists at fniephaus.com
Mon Apr 2 16:27:42 UTC 2018


Hi Nicolas,

On Mon, Apr 2, 2018 at 6:21 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

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

Sure, feel free to send me a PR :)


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

"Stages group jobs that run in parallel, while their stages run
sequentially" [1].

[1] https://docs.travis-ci.com/user/build-stages/#What-are-Build-Stages%3F


>
> 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 at 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/6ad49f43/attachment.html>


More information about the Vm-dev mailing list