[ovirt-devel] Re: GitHub Actions-based CI for vdsm

On Sun, Nov 28, 2021 at 12:41 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > > On Fri, Nov 26, 2021 at 7:44 PM Marcin Sobczyk <msobczyk(a)redhat.com&gt; wrote: > > > > Hi All, > > > > I've been working on adding GitHub Actions-based CI to vdsm today. > > Feel free to check out the patches here: > > > > https://gerrit.ovirt.org/q/topic:%22github-actions-ci%22+(status:open%20O... > > Awesome! > > > Some comments: > > - the linters work fine already, we can start using them > > > > - RPM building works too in general. I think the RPM versions are not > > right yet, rpm versions are corrected by: - pushing current master to your fork - pushing --tags to your fork - using "check-depth: 0" option for actions/checkout@v2 > so I'll look into this. After the 'rpm' job is done we get a > > zipfile with all the built RPMs inside. In the future we may want to run > > 'createrepo_c' on this dir as well, so we'll have a ready-to-be-used > > repository in that zip. > > We already have code to do this in automation/common.sh - can we > reuse it or extract it to new script? > > > - 'tests' are working too, but we have a couple of failures we'd need to > > look at. This job, unlike the others, runs in GitHub's Ubuntu VM inside > > which we use a privileged container for running the tests. > > The failure seems to be missing TRAVIS_CI=1 environment variable. > This should of course change to something moer generic like CONTAINER_CI=1 > and the helper modules tests/testing.py should be updated. Tests pass adding env: TRAVIS_CI=1 Ugly but works :-) > > - didn't try 'tests-storage' yet > > That's fine, the storage team will handle this. Added storage tests here: https://github.com/nirs/vdsm/commit/0e5282945e4c86e65d5a1c12987e7534f350f2f2 > > - Not to waist precious free CI minutes and storage, we run linters > > first, tests after that, but only under the condition that the linters > > didn't fail, and finally we build RPMs, but this time under the > > condition that the tests didn't fail. > > This is very bad idea. We want to run all the jobs in parallel so we > can get quick feedback from all jobs at the same run. There is no real > dependency between the jobs, and we don't waste resources by running > them in parallel. Here is a build with all jobs running in parallel, finish in 6.5 minutes: https://github.com/nirs/vdsm/actions/runs/1512754118 I think we can add install tests to the rpm job. This is at least 3 times faster than jenkins. We can start using github CI now.