hiearchy of build stages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

hiearchy of build stages

Nicolas Cellier
 
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
Reply | Threaded
Open this post in threaded view
|

Re: hiearchy of build stages

alistairgrant
 
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
>
Reply | Threaded
Open this post in threaded view
|

Re: hiearchy of build stages

Nicolas Cellier
 
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?

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
>

Reply | Threaded
Open this post in threaded view
|

Re: hiearchy of build stages

fniephaus
 
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
>

Reply | Threaded
Open this post in threaded view
|

Re: hiearchy of build stages

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



Reply | Threaded
Open this post in threaded view
|

Re: hiearchy of build stages

fniephaus
 
Hi Nicolas,

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

 

2018-04-02 18:05 GMT+02:00 Fabio Niephaus <[hidden email]>:
 
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
>