CI: build and test with vendor compilers, and reorganise the workflows - #1363
Open
ACSimon33 wants to merge 27 commits into
Open
CI: build and test with vendor compilers, and reorganise the workflows#1363ACSimon33 wants to merge 27 commits into
ACSimon33 wants to merge 27 commits into
Conversation
…image versions (don't use latest).
…ses issues (will be resolved later)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds CI coverage for the Fortran compilers the existing pipelines never
exercised — the NAG Fortran Compiler, LLVM Flang, Intel oneAPI and the Arm
Toolchain for Linux — and reorganises the existing workflows so each one has a
single, clear purpose.
New:
Compilersworkflow (compilers.yml)Builds and tests LAPACK with one job per toolchain and library type, 26 jobs in
total (13 toolchains × static/shared, all Release):
Licensing
The NAG compiler is license-managed, and its Kusari key is tied to the platform it was issued for, so each configuration reads a secret of its own:
NAG_KUSARI_KEY_LINUX_X86_64NAG_KUSARI_KEY_LINUX_ARM64NAG_KUSARI_KEY_MACOS_ARM64I added license keys that are valid until the end of the year. I'll update them once they expire. Pipelines will be skipped when the keys are no longer valid or accessible (e.g., in PR pipelines).
Reorganised existing workflows
cmake.yml→special.yml("Special Build Configurations"), now holdingonly the configurations that are genuinely special, 14 jobs: the OpenMP
build, extended-API-only, CBLAS/LAPACKE without a Fortran compiler, the
valgrind memory check and gcov coverage. The plain GNU builds it used to run
are covered by the Compilers workflow.
makefile.yml— the two near-identical per-platform jobs collapsed intoone matrix job, now covering four platforms instead of two.
-latest, theninja-buildinstall steps dropped (Ninja 1.13.2 is on every image),all actions updated and pinned by commit SHA, and every job given an
explicit name.
Windows pipelines
Since we now also cover the native Windows pipelines in the new workflow, we could get rid of the AppVeyor builds. The AppVeyor builds use older compiler but otherwise they are not really useful anymore. They are also quite slow....
Memcheck job
During the refactoring, I noticed that the Valgrind job actually doesn't run through the LAPACK test suite. Because it lacks
--trace-children=yes, only the CMake process (runtest.cmake) is instrumented by Valgrind but not the actual test binary. I'll fix this in a follow-up PR because Valgrind raises some real issues, which I'll resolve there as well.Closes #1258