Alpaka: Travis: Stages

[ax3l]

Travis does support build stages (pipelines) now! :)

With that, we can e.g. group our tests for the fastest first and if they fail, we don't even start the more expensive ones.

This would be great, since Travis parallelism is accounted GitHub organization-wide and has side effects to other projects in the CRP group :)

[BenjaminW3]

Currently a large part of the CI time is downloading and installing the dependencies, building boost, etc. The compilation and execution of the tests are (depending on the job) 20%-60% of the time of a job.
Tests are not executed for CUDA, because, you know, this would require NVIDIA hardware.
There are no really long running tests. What takes most of the time is the compilation.

The problem I see with staging the tests is that for each configuration (compiler, flags, cmake, CUDA, ...) which currently define a job, we would create a second job to execute the second half of the tests. This would duplicate the whole initial phase of test preparation because It is important to note that jobs do not share storage, as each job runs in a fresh VM or container.

Currently only the long running downloads of clang, cmake and CUDA are cached within the travis cache.
My long term goal is to build (a) docker image(s) which contains everything to build alpaka. Those can then be cached by travis or stored somewhere else. My work in #397 was the first step in this direction by extracting all the scripts out of the .travis.yml file. However, this will take some time.

[BenjaminW3]

A short term solution that I see, is moving alpaka back to my personal github account. Then all the alpaka testing would be counted to my budget independent of the other CRP projects.

[ax3l]

we would create a second job to execute the second half of the tests

the stages themselves of the same job share stored, see for example the pre-caching example where the first stage installs the dependencies and the others use them.

My long term goal is to build (a) docker image(s) which contains everything to build alpaka

this sounds all right, maybe our upcoming CI infrastructure at HZDR can also be deployed for GitHub tests. We could also try to use spack and its build caches. At the end it all ends in the same goal: installing all dependencies as pre-build "binary" artifacts.

One could also think if really every test needs to be a PR test or if travis cronjobs can be deployed for some aspects.

A short term solution that I see, is moving alpaka back to my personal github account. Then all the alpaka testing would be counted to my budget independent of the other CRP projects.

I think that's not necessary and causes more confusion. Just continue to push new feature branches to your fork before you open the PR, so the mainline org does only test PRs and not development branches.

[BenjaminW3]

967 discusses the future of our CI and especially providing prebuilt docker images as build environment. Furthermore, we are moving from travis to github actions. Therefore I will close this ticket.