WIP: Resolve "Test with larger variety of distributions/compilers"

changed the description

changed milestone to %ICRC2019

assigned to @lukas

We use an open discussion to mimic MR APPROVALS, @hdembinski, please follow this up when the MR is not WIP any more, and approve afterwards when ready. Thanks!.

Hi Ralf, I cannot follow, what do you mean by "MR APPROVALS" and what by "when the MR is not WIP any more"?

I suppose MR = Merge Request and WIP is work in progress, I got it so far, but there are no commits in the MR.

True, Lukas has not added anything yet. This is why this MR is still labelled Work-in-progress (WIP) in the very top. Approval only starts after all changes have been committed to the branch and the author (Lukas) tell us he is ready. In this case here we have to wait a bit further.

I'll look into this later this week, got to get an auger code release out right now.

I have a large number of containers ready, we should decide what we want to run by default and what we want to run periodically. Have a look at AirShowerPhysics/corsika-docker> to see what is prepared.

Do we need the MR APPROVALS stuff? I thought WIP means that a merge request is not yet ready for merging, but other developers can have a look at the related branch already and comment. Once the WIP prefix is removed, the MR is ready for final review and approval, followed by merging by one of the maintainers.

We might consider getting full open source status for the CORSIKA 8 project. That should provide us with a license to use the features that are currently locked, like a formal approval procedure.

Lukas, what are plans here. Do you have any local commit already? There will be an eventual overlap with !125 (merged), we could either keep them distinct, or we combine the two merge requests.

Can you please add containers for Ubuntu 20.04 LTS ? This would be logical and great.

Done. We should see if we want to update some of the components shipped in the container. Boost comes to mind.

For the pipelines it would be great to have clang-format included. Right now we run

apt-get update && apt-get install -y -qq clang-format

as part of the jobs. In fact, we do not require boost since we ship all needed boost headers together with corsika right now...

When the new containers are ready for use, please tell me how to update the image: corsika/devel:u-18.04 and corsika/devel:clang-8 in the .gitlab-ci.yml file.

Thanks!

I would like to add apt-get install python3 apt-get install python3-dev

to the requirements of the runners. In the near future with python bindings, this will be necessary and should be easily available on nearly all platforms.

I have updated some containers for other projects and would look next week into updating the container(s) for CORSIKA with the right packages pre-installed. Can we make a full list of the containers we want to have?

We need at least the gcc versions of ubuntu18.04, ubuntu20.04, as well as clang-8 (maybe clang-9?).

As shown in #291 (closed) there already is a bug in QGSJetII depending on the compiler version....

If it's not too much effort flang or f18 would be nice as alternative FORTRAN compiler.

We should have always two main containers for testing, one with a mainstream gcc (v7) and one with a mainstream clang (v8). Besides this it makes sense to have a least one alternative version of either of gcc (suggest v9 now) and clang (suggest v9 or v10 now(?)).

These are two to four containers.

To add other dedicated containers is also a good idea, I think a recent gcc combined with flang would be great. However, I am pretty sure we will run into problems surprisingly quickly and often if we extend our testing too extensively. And we don't always have the energy to solve things like #291 (closed) (gfortran v9 is strange), I am also not sure why the clang (v8) test of !202 (closed) is failing right now (?).

Btw: we can only increase our regular system testing matrix if we increase our gitlab runner performance simultaneously. We have to keep the CI turnaround as short as possible. We need more active Runner cores than we are using test containers. Right now we only have effectively 1 Runner, but 2 containers...

I managed to get the runner two run multiple instances in parallel. The pipline fails due to the way it is set up. Reduced concurrency of the runner back to one. Caching, unique working directories, and concurrent running have some complicated interactions.

Lukas, if you setup the runners to run in parallel -- even if this fails -- I can work on fixing it "live". Otherwise I won't be able to understand the interaction between caching, working directories etc.

We need to sit down at some point soon (maybe together with Remy) and sort out the problems with the Runners. This continues to slow us down and needs to be solved.