Move Vagrant-based tests from GitHub Actions to Cirrus CI#6854
Move Vagrant-based tests from GitHub Actions to Cirrus CI#6854dmcgowan merged 1 commit intocontainerd:mainfrom
Conversation
|
Skipping CI for Draft Pull Request. |
ab3a2d8 to
59e308d
Compare
|
@AkihiroSuda - runc has been using Cirrus CI. Would you recommend containerd to move from GitHub Actions to Cirrus CI as well regarding Vagrant-based tests? @cpuguy83 - Some of the reporting you've added wouldn't work on Cirrus CI. Would it be a blocker? |
|
Cirrus CI also supports FreeBSD, which would make it possible to test containerd with the runj shim. |
|
Build succeeded.
|
Definitely 😞 but it won't break anything. |
|
Build succeeded.
|
2413c75 to
77413f3
Compare
|
Build succeeded.
|
a1f7941 to
4ce162a
Compare
|
Build succeeded.
|
87f6c72 to
f7a7b80
Compare
|
Build succeeded.
|
|
Build succeeded.
|
|
Build succeeded.
|
|
Build succeeded.
|
a58ddb3 to
d985b77
Compare
|
Build succeeded.
|
6832c1e to
6dad8a5
Compare
|
Build succeeded.
|
.cirrus.yml
Outdated
| # | ||
| # Undocumented constraints; | ||
| # - The maximum memory limit is 4G times the number of CPUs. | ||
| # - The number of CPUs should be mutiple of 2. |
| HOME: /root | ||
| matrix: | ||
| BOX: fedora/35-cloud-base | ||
| BOX: rockylinux/8 |
There was a problem hiding this comment.
(We could just use GCP rockylinux image without Vagrant, but that may rather complicate the script, so using Vagrant seems fine)
There was a problem hiding this comment.
Yeah. We technically could maintain images with our own dependencies to speed up the build, but I'm unsure it is worth to do.
Vagrantfile
Outdated
| config.vm.provider :libvirt do |v| | ||
| v.memory = memory | ||
| v.cpus = cpus | ||
| v.machine_virtual_size = 60 |
There was a problem hiding this comment.
Can we apply the same disk size configuration to :virtualbox provider too?
https://www.vagrantup.com/docs/disks/usage
There was a problem hiding this comment.
Sure. It is experimental though.
|
Sadly I had to re-run "Cirrus CI / Vagrant BOX:rockylinux/8" once. I'm unsure that the instability was coming from our tests or Cirrus CI. Good news is that other two tests were finishing earlier than "CI / Windows Integration (windows-2022)" and "CI / Linux Integration (io.containerd.runc.v1, runc)". If this trend continues, Cirrus CI wouldn't be our bottleneck, in terms of its speed. |
Cirrus CI supports nested virtualization and free to use from open source projects. runc has been using the service since opencontainers/runc#3088. Signed-off-by: Kazuyoshi Kato <[email protected]>
|
Build succeeded.
|
Cirrus CI supports nested virtualization and free to use from open
source projects. runc has been using the service since
opencontainers/runc#3088.
Signed-off-by: Kazuyoshi Kato [email protected]