hiearchy of build stages

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?

Cheers,
Alistair


On 2 April 2018 at 15:25, Nicolas Cellier

<[hidden email]> 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.
>
> 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
>

 

Hi all,

On Mon, Apr 2, 2018 at 3:36 PM Nicolas Cellier <[hidden email]> 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 <[hidden email]>:

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

<[hidden email]> 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
>