condensing Travis build matrix

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

condensing Travis build matrix

Ben Coman
 
As I commenced looking into building Windows on Travis, I was a bit overwhelmed by the prospect of later needing to add a "windows" axis to the ".travis.yml"  build matrix.  
I find it hard to determine the coverage of the current arrangement where
all the jobs are individually defined.

Also I had noticed that the build overall takes longer with smaller stages since 
while waiting for the last job of a stage you don't have five parallel jobs running. 

So I went digging and devised an alternate arrangement such that:
* full coverage matrix auto generated
* production jobs pulled from the coverage matrix into their own stage up top
* order of stages can be changed by a single line
* allow_failures can be changed for a whole stage by a single line
* sista and lowcode grouped into one 'experimental' stage allowed to fail
* aliases used to not-repeat-oneself (it was painful in the exclude sections
  coming to terms with 'env:' definitions needing to match exact whitespace)
* when it comes time to add coverage for Windows, this can be done with a single line

I'd love some feedback on it...

Here are the jobs it produces... 

and here are the jobs produced by un-commenting line 80 to add coverage for windows...

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: condensing Travis build matrix

fniephaus
 
On Sun, Jan 20, 2019 at 5:37 AM Ben Coman <[hidden email]> wrote:

>
>
> As I commenced looking into building Windows on Travis, I was a bit overwhelmed by the prospect of later needing to add a "windows" axis to the ".travis.yml"  build matrix.
> I find it hard to determine the coverage of the current arrangement where
> all the jobs are individually defined.
>
> Also I had noticed that the build overall takes longer with smaller stages since
> while waiting for the last job of a stage you don't have five parallel jobs running.
>
> So I went digging and devised an alternate arrangement such that:
> * full coverage matrix auto generated
> * production jobs pulled from the coverage matrix into their own stage up top
> * order of stages can be changed by a single line
> * allow_failures can be changed for a whole stage by a single line
> * sista and lowcode grouped into one 'experimental' stage allowed to fail
> * aliases used to not-repeat-oneself (it was painful in the exclude sections
>   coming to terms with 'env:' definitions needing to match exact whitespace)
> * when it comes time to add coverage for Windows, this can be done with a single line
>
> I'd love some feedback on it...
> https://github.com/bencoman/opensmalltalk-vm/blob/1358adf/.travis.yml

I don't have strong opinions on this change. I think it's important
that it works and even more important that others (e.g. Eliot)
understand what is going on in this file. Maybe someone else could
comment on that?

While you're at it, I would really like to see the number of build
jobs to decrease, to increase our feedback loops mostly. I know we
want to keep backwards compatible components alive as long as
possible, but I guess we'll have to drop 32bit at some point in the
future. Why don't we combine 32/64bit build jobs in the meantime? Each
build could start with compiling the 64bit version, then it installs
32bit dependencies and compiles the 32bit version. Obviously, the
build would fail as soon as each of these steps fails. What do you
think? Caching on CI-level might be a problem thought.

Fabio

>
> Here are the jobs it produces...
> https://travis-ci.org/bencoman/opensmalltalk-vm/builds/481940940
>
> and here are the jobs produced by un-commenting line 80 to add coverage for windows...
> https://travis-ci.org/bencoman/opensmalltalk-vm/builds/481941445
>
> cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: condensing Travis build matrix

Eliot Miranda-2
 


On Sun, Jan 20, 2019 at 1:46 PM Fabio Niephaus <[hidden email]> wrote:
 
On Sun, Jan 20, 2019 at 5:37 AM Ben Coman <[hidden email]> wrote:
>
>
> As I commenced looking into building Windows on Travis, I was a bit overwhelmed by the prospect of later needing to add a "windows" axis to the ".travis.yml"  build matrix.
> I find it hard to determine the coverage of the current arrangement where
> all the jobs are individually defined.
>
> Also I had noticed that the build overall takes longer with smaller stages since
> while waiting for the last job of a stage you don't have five parallel jobs running.
>
> So I went digging and devised an alternate arrangement such that:
> * full coverage matrix auto generated
> * production jobs pulled from the coverage matrix into their own stage up top
> * order of stages can be changed by a single line
> * allow_failures can be changed for a whole stage by a single line
> * sista and lowcode grouped into one 'experimental' stage allowed to fail
> * aliases used to not-repeat-oneself (it was painful in the exclude sections
>   coming to terms with 'env:' definitions needing to match exact whitespace)
> * when it comes time to add coverage for Windows, this can be done with a single line
>
> I'd love some feedback on it...
> https://github.com/bencoman/opensmalltalk-vm/blob/1358adf/.travis.yml

I don't have strong opinions on this change. I think it's important
that it works and even more important that others (e.g. Eliot)
understand what is going on in this file. Maybe someone else could
comment on that?

I'll try, but I have never looked at it.  I'd rather not have to grok it (gulp).
 

While you're at it, I would really like to see the number of build
jobs to decrease, to increase our feedback loops mostly. I know we
want to keep backwards compatible components alive as long as
possible, but I guess we'll have to drop 32bit at some point in the
future. Why don't we combine 32/64bit build jobs in the meantime? Each
build could start with compiling the 64bit version, then it installs
32bit dependencies and compiles the 32bit version. Obviously, the
build would fail as soon as each of these steps fails. What do you
think? Caching on CI-level might be a problem thought.

I like that idea.  I also see no point in building the ARM Newspeak builds (unless the Newspeak folks say otherwise).
 
Fabio

>
> Here are the jobs it produces...
> https://travis-ci.org/bencoman/opensmalltalk-vm/builds/481940940
>
> and here are the jobs produced by un-commenting line 80 to add coverage for windows...
> https://travis-ci.org/bencoman/opensmalltalk-vm/builds/481941445
>
> cheers -ben


--
_,,,^..^,,,_
best, Eliot