Draft: Add new compiler and enable ruby builds

[keithhealy]

First stage of Gitlab CI work.

1. Added 8.3.1 compiler host config
2. Modified build and test script to look for host configs in SAMRAL repo not radiuss-ci.
3. Simplified Gitlab staging since really only one stage is doing useful work.
4. Added Ruby testing back.

[keithhealy]

The Gitlab CI run for merge requests appears to be working now. It's failing though, I think because the user (Adrien) doesn't have access to the TPLs. The host configs in radiuss-ci don't appear to have been updated in ~3 years. I need to check whether it is still an active project. For now I'm using the host configs in SAMRAI/host-configs.
Starting to look at using spack to build TPLs for other compilers. (TPLs only exist for 8.3.1 now) Existing Gitlab yaml mentions Lassen and Butte, Is testing on these platforms something you want to do?

[rhornung67]

@keithhealy the radiuss-shared-ci and radiuss-spack-configs repos are being updated. We are testing across multiple projects (RAJA, Umpire, etc.) and coordinating PR merges across multiple projects. We use Spack to generate host-config files during each GitLab CI run. The specs are maintained in https://github.com/LLNL/radiuss-spack-configs. Updated Spack packages are also maintained in that project. They are updated with each release of the projects and then upstreamed collectively to the Spack repo. Which host config files are you referring to?

This PR https://github.com/LLNL/radiuss-spack-configs/pull/49 contains updated Spack specs for all the LC platforms, except for the latest ROCm compiler releases. Our plan is to have everything current with the compilers that WSC/CP apps are using for production builds soon.

Adrien is taking vacation and will be back next week, I believe.

[keithhealy]

@rhornung67 I was looking at these host-configs: https://github.com/LLNL/radiuss-ci/tree/f4e490e571af8341c1305362f0894856c4ff9ad4/gitlab/conf/host-configs/toss_3_x86_64_ib since radiuss-ci is a submodule in SAMRAI.
It looks like development has moved to radiuss-shared-ci then?

[rhornung67]

@keithhealy yes, the radiuss-ci repo is old. radiuss-shared-ci is the framework we use to drive GItLab CI on LC from GitHub projects. It is developed on GitHub and then mirrored to the LC CZ GitLab. It contains template files that you can customize for a project. The docs are here: https://radiuss-shared-ci.readthedocs.io/en/latest/. It needs some polishing. To use it, you need to have radiuss-spack-configs and uberenv as submodules in the SAMRAI repo (see the link below to the RAJA Dev Guide section).

Here's some documentation on how we use these projects in RAJA GitLab CI https://raja.readthedocs.io/en/develop/sphinx/dev_guide/ci.html Umpire, etc. are doing the same thing. I can help with with some things on the user project side. For more complex questions, please post an issue to the radiuss-shared-ci GitHub project, or try contacting Adrien directly.

[nselliott]

Thanks @keithhealy . As @rhornung67 has suggested, we'll need to switch to radiuss-shared-ci instead of radiuss-ci. If you can get spack builds of the TPLs in place, that would be a stronger solution than my installed versions.

[keithhealy]

@rhornung67 Thanks for the info. I will add the new submodules and review the documentation you have provided. @nselliott My goal will be to move SAMRAI CI to the radiuss-shared-ci template including the building of TPLs.

[rhornung67]

@keithhealy @nselliott I think you should be able to follow an approach similar to Axom for sharable Spack builds of TPLs. This is not covered by the radiuss-shared-ci stuff. But, I think it should be easy to hook in.

[adrienbernede]

@keithhealy please use the process described in RADIUSS Shared CI user guide: https://radiuss-shared-ci.readthedocs.io/en/latest/sphinx/user_guide/index.html

I suggest that you keep the optimization of TPL builds for later, the CI may be slow at first, but it’s better to start simple.

Also, note that you will have to stick to uberenv@1.0.0 for the shared CI to work, do not update the submodule to main.

We will update the specs promptly in RADIUSS Shared CI so that you can directly work with the most relevant specs instead of the old ones.