Re: Stick with Travis for continuous integration, or switch?

[Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Thu, 21 Jan 2021 03:24:12 +0000
>
> On Mon, 18 Jan 2021 22:29:21 -0800
> Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>
> wrote:
>
> > Travis CI is announcing on the travis-ci.org site that "...
> > travis-ci.org will be shutting down in several weeks, with all
> > accounts migrating to travis-ci.com. Please stay tuned here for more
> > information."
> >
> > They don't provide any information there.  However, at
>
> Thank you for collating a comprehensive problem statement. I had
> noticed the banner a few weeks ago, but before raising this decided to
> take some time to practise the migration on repositories other than the
> main tcpdump/libpcap repositories. Some information is missing and other
> information is inconsistent or difficult to match with the web control
> panel, but after a while I managed to get the hang of it.
>
> [...]
>
> >               * For those of you who have been building on public
> > repositories (on travis-ci.com, with no paid subscription), we will
> > upgrade you to our trial (free) plan with a 10K credit allotment
> > (which allows around 1000 minutes in a Linux environment).
>
> [...]
>
> > We haven't been building on travis-ci.com, so presumably the first
> > item in the list doesn't apply.  If the "We will be offering an
> > allotment..." part applies, the "should your run out of credits again
> > you can repeat the process to request more or discuss a renewable
> > amount" seems like a pain.
>
> In practical terms it means that all new accounts on travis-ci.com
> default to the free plan with 10000 credits gratis one-off. The credits
> burn down at different rates depending on the OS. The tcpdump group is
> at 9970/10000 now.
>
> [...]
>
> > I guess we meet those requirements, although I'm not too keen on
> > having to keep going hat-in-hand to them every time we run out of
> > credits; hopefully, we can just get a renewable amount.
>
> Re requirements: yes. Re renewable: it would be reasonable to expect it.
>
> In the worst case it will be $70/month for the cheapest plan. In the
> case of a monthly FOSS allowance it may be not large enough to
> accommodate the current setup, which is a full round of the following
> work for every master push and pull request:
>
> tcpdump: 108 jobs, of which 12 are macOS
> libpcap: 36 jobs, of which 4 are macOS
>
> Which in practical terms would mean that committers need to remember to
> skip CI when appropriate (to skip all three CI systems put "[skip ci]"
> on the git commit summary line, see my message from 21/08/2020 for
> details). Also it may make sense to make the default CI matrix smaller,
> and to run the full CI round manually (same as Coverity) or once a
> week/month automatically. In any case, it is practicable.
>
> > Frankly, I agree with the reply to that comment where they say
> >
> >       I wonder if travis thinks they have something to gain in
> > reputation by letting this info out in dribs and drabs, making it
> > very hard to figure out what is actually going on.
> >
> > So we can either migrate to travis-ci.com or use other providers.
>
> To me it would make the most sense to migrate to the hello-real-world
> version of Travis CI for now if and where possible, and to take time to
> consider any long-term changes.
>
> > We're currently using AppVeyor for Windows builds and Cirrus CI for
> > FreeBSD builds.
>
> Beware that Cirrus documentation and feature set are nowhere near
> Travis. I had added Cirrus CI because at the time it was the only way
> to get FreeBSD. Travis documentation now has a minimal notion of
> experimental FreeBSD support, but no particulars yet.
>
> > AppVeyor offers Windows, Linux, and macOS; Cirrus offers those plus
> > FreeBSD.  Neither of those have, as far as I know, decided to
> > complicate the process of using them for free software projects.
>
> Maybe they have deeper pockets, or fewer free workloads to piggy-back,
> or both.
>
> > The only thing I see that Travis offers that others don't is non-x86
> > builds - they support:
> >
> >       ppc64le - useful for tcpdump given that at least one bug
> > popped up only there (we were "cheating" in the use of a crypto
> > library, and only the ppc64le build of that library relied on the
> > program not cheating);
> >
> >       arm64 for Linux - that may become a more common platform over
> > time (I don't know whether it requires strict alignment for 2-byte
> > and 4-byte loads - as I remember from reading the ARMv8-A
> > documentation, there's a control register bit to indicate whether to
> > fault or allow unaligned accesses, and I haven't checked whether
> > Linux enables them or not);
> >
> >       s390x (a/k/a z/Architecture, i.e. S/3x0-64) - a big-endian
> > platform, so we can do some testing of operation on big-endian
> > machines.
> >
> > I don't know whether any other CI products that offer free service to
> > free-software projects support non-x86 platforms.
>
> Just that alone puts Travis way ahead of most other services.
>
> -- 
>     Denis Ovsienko
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers