-
Notifications
You must be signed in to change notification settings - Fork 7
add EESSI version 2025.06 to CI workflows #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
The accelerator detection is still failing, as we don't have those directories yet (we only have EESSI + EB for the CPU targets). The hooks CI is failing due to #39 not being merged yet (but it is deployed already). |
@@ -33,7 +34,7 @@ jobs: | |||
for shell in $(ls init/lmod); do | |||
sed -i "s/__EESSI_VERSION_DEFAULT__/${{matrix.EESSI_VERSION}}/g" init/lmod/${shell} | |||
done | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that .github/workflows/scripts/test_init_scripts.sh
is currently version specific (causing this CI to fail)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from this, the rest of the CI is set up so that it will only pass once the accelerator directories actually exist. To get it it to pass we could manually create the structure?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we build a relevant CUDA first and then fix the CI
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can easily remove that hardcoded EESSI_VERSION
in .github/workflows/scripts/test_init_scripts.sh
. However, it's also loading a particular module (https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/scripts/test_init_scripts.sh#L34), how do we deal with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can have it load EasyBuild/5.1.1
and use eb --version
instead, that specific version appears in both.
You could also use an environment variable that might be EESSI version specific and use that, I did that in https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/scripts/verify_eessi_environment.py#L49 (via https://github.com/EESSI/software-layer-scripts/blob/main/.github/workflows/tests_eessi_module.yml#L196)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That CI workflow is now checking for an EB version (which can be specified in the workflow matrix), and this seems to work. For the accelerators I guess we should indeed just do a CUDA build soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we do this piece by piece, fixing the things we can first.
For the specific case of accelerators, we can enable it once the directory exists. I wonder if there are different ways to fail? Can we report an "unable to run" if a comparison directory does not exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems it can at least be made more visual:
echo "::warning:: Forced to skip check, comparison directory {} does not exist"
No description provided.