[intel-iot-refkit] speeding up CI builds

[Patrick Ohly]

Hello!

Olev recently noticed that compressing images can be quite slow (several
minutes) and happens to be on the critical path. I looked into disabling
the compressed image variants (like wic.xz) for the oe-selftest. But at
least for the installer image tests that forces a rebuild of the
installer image, which defeats the original goal of using the image that
was already built earlier during the main build.

We don't publish images for every pull request test build, do we? So I
think it would be best if we disabled the

        REFKIT_VM_IMAGE_TYPES = "wic.xz wic.zip wic.bmap
        wic.xz.sha256sum"

from refkit-ci.inc completely for pull request tests. Is it possible to
export some variable similar to BUILD_ID which exports the type of the
build to refkit-ci.inc? Then we can limit the change above to master
builds.

This leads me to another observation. We are starting to add
oe-selftests that by themselves take much longer than the actual build.
We have to, because we need these tests to ensure that our features
don't regress.

Build time with PR #147 merged will be around 2:15. This may go down
again when updating OE-core (which has a patch that avoids unnecessary
image rebuilding), but eventually we are going to have to deal with
multi-hour build tests again.

I see some potential solutions:
     1. parallelize some of our oe-selftests, like OE-core is currently
        doing
     2. run only fast and/or selected (*) selftests for PRs, merge them
        into a master-next branch, and only do full testing of
        master-next before promoting that to master

I'm not sure how much parallelization will really help us.

(*) with "selected" I meant "selected by the author of the PR". If I add
a new feature and have new tests for that, I need a way to trigger those
tests for that PR. The mechanism for that would have to be defined and
implemented. Perhaps some annotations in the PR description which gets
exported to bitbake and thus refkit-ci.inc?

Any other opinions?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.