CI on Travis now using containers

Hello all,

In the past few months we’ve seen Travis getting slower and slower to even pick up our PRs for testing, and observing in their status page we can see that part of the reason is that they are overbooked on the VM-based runners. That said, pretty much every time this happened and we looked the container-based infrastructure was still without any backlog.

Considering that, we’re about to merge @mvo’s PR #3960 which moves our Travis configuration to use containers instead of full VMs. As a result we expect a significantly faster response time of the CI machinery when PRs are pushed or changed.

A couple of notes on the change for when we need to touch this again:

  • We need Travis to use the Go language, even if there’s nothing to build. That’s because their Go backend will make sure to checkout the git repository on the proper path ($GOPATH semantics)
  • We need an install: section to exist too, even if it does nothing. Otherwise Travis will come up with its own default install section, which doesn’t work for us.

Please let me know if you see any issues related to this.

2 Likes

Isn’t this going to invalidate apparmor tests? AppArmor in a container isn’t guaranteed to be enabled without some effort (including lxd and Ubuntu kernels).

It’s been a long while since we’ve run any tests on Travis itself. We use it just to run Spread and ship the real testing to about two dozen machines elsewhere, running various versions of various Linux distributions.

1 Like