Update report creation to use texlive/2022

Description

It looks like texlive/2022 will be the oldest - and for now only - version of texlive available after the update to EL9. So we will need to update report creation to use that. Hopefully this will just work with no other changes.

This should affect both new calibration jobs and repeating old ones.

How Has This Been Tested?

To be tested in CI.

Types of changes

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the code style of this project.

Reviewers

@schmidtp @ahmedk

ERROR: Unable to locate a modulefile for 'texlive/2022'

I don't understand that. The /etc/modulefiles/texlive/ folder contains both 2019 and 2022, and I can module load texlive/2022 interactively with no problem.

This is running in our regular CI on bare metal, not a container?

I thought that was the case, but @roscar actually just reminded me in Zulip that our regular CI is actually also containerised, but differently. So now it makes sense: the modulefile for texlive/2019 is bind mounted into the container, but the one for texlive/2022 isn't.

added 1 commit

• 8e2dd197 - Run integration tests on new non-container runner

Compare with previous version

added 1 commit

• 24777945 - Set Python version to 3.8 for integration tests

Compare with previous version

added 1 commit

• 0fe177b4 - Ensure integration tests talk to exflcalproxy

Compare with previous version

We finally got all integration tests passing with the new shell CI runner. I think we agreed we'll merge this at the end of the current cycle, so we're not relying on the new runner while we might still need to work on fixes.

I believe this should get us ready for EL9, give or take rebuilding Python 3.8 from pyenv. We also said we'll set up a shell CI runner on our max-exfl458 EL9 node so we can do some more testing.

Is the tag addition relevant for this MR? And if yes, why the name integration I don't have anything against the name, I am just curious to know if it's connected to this particular test stage (and if it would benefit or not from using the same stage name) or not.

LGTM

Thanks for the tedious testing, LGTM!

Merging, thanks for the reviews.

Be aware that the integration tests will now use the new 'shell' CI runner. Previously all the CI has been run in Singularity containers, with a bunch of bind mounts to make everything work. The integration tests now won't be in a container, so they are closer to how calibration runs in production (but still with some sandboxing).

Relatedly, but as a separate step (see !984 (merged)), the regular part of CI, which runs without a manual trigger, will switch from using Singularity containers to Docker containers, and get more restrictions (fewer bind mounts).

merged

mentioned in commit bd6d7cc5

changed milestone to %3.14.3