Sorry for the late reply, just catching up on my email after the holidays.
Is it possible to have two different CI setups? That is, a fast and a slow
setup, both of which test the same repository? My thought is that you could
have the fast setup that you check all the time, and a slow setup that runs,
but is checked only infrequently. No idea if that is possible with Circle CI
(or anything else for that matter), but it may help prevent bitrot down the
road.
Thanks,
Cem Karan
________________________________
From: nanomsg-bounce@xxxxxxxxxxxxx [nanomsg-bounce@xxxxxxxxxxxxx] on behalf of
Garrett D'Amore [garrett@xxxxxxxxxx]
Sent: Thursday, December 28, 2017 7:29 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] CI changes coming for nng
I spend an inordinate amount of my time waiting for the CI to complete — as a
result I’m always looking for ways to shorten the cycle. To that end, some
changes are coming to the CI we do for nng:
a) I’m moving from Travis to Circle CI for Linux builds. From my testing,
their 2.0 infrastructure is *lots* faster than Travis.
b) I’m planning to stop testing all the various different build tools. CMake
drives everything, but making a ninja target means I get very clean and easy to
read results a *lot* faster than using make, and a *lot more* faster than using
Visual Studio. (The other build systems will still work, I’m just not going to
keep testing them. That was always more of a validation of CMake than of
anything I’ve done, and I’m just interesting in acting as the QA department for
CMake.)
c) macOS builds will be disabled for now. The Travis mac infra is terrible,
with queue times upwards of 20 minutes sometimes, and build systems are so
overloaded that my timer related platform checks frequently fail simply because
of the enormous dispatch latency caused by severe load. (I expect 20 ms
dispatch latency or better, and the observed values exceed the test limits of
50 ms. This is something new in the Travis environment — I think they are
hosting things in a way that the quality has degraded.) I’m hoping to be able
to use the Circle CI macOS infra as well, but until I validate it the CI will
be disabled for macOS.
d) The test matrix — especially for appveyor, is going to get a lot smaller. I
will probably only test the latest version of Visual Studio. The older ones
will still work, but I’m not interested in waiting to get such test results for
every one of my commits. I’ll probably only do 32 and 64 bit tests on Windows
for now.
e) Likewise I’m going to stop testing so many different versions of Linux.
f) Older versions of compilers, operating systems, or build tools will be
supported on a “best effort” basis, which means I’m not going to go too far
out of my way to keep them going, but I won’t knowingly break them either. If
someone wants support for something older, and has a commercial need for higher
levels of support, please contact me and we can work out some kind of
arrangement.
Let me know if you have any questions or concerns.
Thanks!
- Garrett
