[Scons-dev] revisiting CI setup
Bill Deegan
bill at baddogconsulting.com
Mon Dec 16 15:30:06 EST 2019
I'd say since appveyor windows builds have sped up so much we can decrease
the split per py type from /4 to maybe /2 or maybe /1
I think the max runtime per build is 1hr?
On Mon, Dec 16, 2019 at 2:26 PM Mats Wichmann <mats at wichmann.us> wrote:
>
> time passes... so time to ask some questions again.
>
>
> The travis build does two code-coverage runs (2.7 and 3.6), then seven
> regular runs (2.7, 3.5, 3.6, 3.7, 3.8-dev, pypy2 and pypy3.
>
> The appveyor build, despite a recent caching hack that sped it up a lot,
> is still much slower, and thus is asked to do less work, but has a more
> complex scenario: it needs to test itself on three different appveyor
> images, each provisioned with a different Visual Studio version, so what
> it runs is: 2.7 on VS2017 image, 3.5 on VS2015 image, 3.6 on VS2017
> image (this is also a coverage run), 3.7 on VS2019 image.
>
> We're having some test problems due to evolution of Windows images - in
> particular (there are github issues on this), clang tests do not run
> properly, because before it always found the mingw clang, but in the
> VS2019 image that is no longer installed by default, and the setup
> doesn't work with a "native" clang - basically this exposed an untested
> issue, rather than breaking something that was working.
>
> 3.8 is fully released now. only the Linux CI (travis) is running the
> tests under 3.8, and it's using "3.8-dev" as opposed to an officially
> released version of 3.8. Although it's early days yet, there ought to be
> a 3.9-dev (last I checked, appveyor hadn't enabled that choice, but that
> was a while back)
>
> what sets of these are actually important for checking that a PR does
> not introduce testing regressions?
>
> I'm unconvinced the pypy tests add any value in this context. Maybe we
> could move them to the buildbot setup instead? In particular, pypy3 has
> never gained the performance of pypy2, and doesn't seem to be in active
> development, and the performance is a killer for our use of it.
>
> We should be able to stop testing 2.7 once develoment flips to "4.0",
> since it won't carry the compatibility promise any longer.
>
> Is there any other way to rearrange/improve this, including the
> mentioned buildbot - things which aren't deemed critical to run on every
> PR but which still would be useful to see the progress of could move to
> buildbot....
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20191216/98692e4a/attachment.html>
More information about the Scons-dev
mailing list