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 |
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 |
On Sun, Jan 20, 2019 at 1:46 PM Fabio Niephaus <[hidden email]> wrote:
I'll try, but I have never looked at it. I'd rather not have to grok it (gulp).
I like that idea. I also see no point in building the ARM Newspeak builds (unless the Newspeak folks say otherwise). Fabio _,,,^..^,,,_ best, Eliot |
Free forum by Nabble | Edit this page |