[Vm-dev] condensing Travis build matrix

[Eliot Miranda]

On Sun, Jan 20, 2019 at 1:46 PM Fabio Niephaus <lists at fniephaus.com> wrote:

>
> On Sun, Jan 20, 2019 at 5:37 AM Ben Coman <btc at openinworld.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190120/f71e3116/attachment.html>