Add check for the existence of EESSI_SITE_SOFTWARE_PATH in EESSI-extend#235
Add check for the existence of EESSI_SITE_SOFTWARE_PATH in EESSI-extend#235casparvl wants to merge 6 commits into
EESSI_SITE_SOFTWARE_PATH in EESSI-extend#235Conversation
…needed if we make this location configurable thourhg EESSI_SITE_SOFTWARE_PREFIX as is done in EESSI#232
|
bot: build repo:eessi.io-2023.06-software instance:eessi-bot-mc-aws for:arch=x86_64/amd/zen2 |
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
| easybuild_installpath = pathJoin(easybuild_installpath, eessi_accelerator_target) | ||
| -- Check that the EESSI_SITE_SOFTWARE_PATH with eessi_accelerator_target prefix exists | ||
| if not isDir(easybuild_installpath) then | ||
| LmodError("The easybuild install directory (" .. easybuild_installpath ..") does not exist or is not a folder") |
There was a problem hiding this comment.
Same here, it doesn't have to exist.
The site paths are special because they are exposed by default. I'll need to check the other PR to make sure there is no check for their existence before adding them to MODULEPATH...when I build something for the site I expect everyone to see it even if their session started before the path existed. Lmod is fine with adding non-existent paths.
|
Oh, reading the initial comment it seems I asked for this. I wonder what I asked for...or more accurately what I think I meant. |
|
Note: we should also deploy EESSI-extend changes to the RISC-V repo. Triggering a build already, so we won't forget about it: bot: build repo:dev.eessi.io-riscv-2025.06-001 instance:eessi-bot-riscv for:arch=riscv64/generic |
|
New job on instance
|
|
Just an FYI: the tarballs for these builds ended up in the same job as EESSI/compatibility-layer#235 . This messed up the deployment of that compat layer PR, so I manually changed the result status of all the above builds to Long term, we should probably make sure these collisions can't occur (i.e. change the bot). Short term: if we want to do this PR, we should wait for EESSI/compatibility-layer#235 to be deployed, then rebuild here, then deploy. |
Co-authored-by: ocaisa <alan.ocais@cecam.org>
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
bot: build repo:eessi.io-2025.06-software instance:eessi-bot-mc-aws for:arch=x86_64/amd/zen2 |
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
New job on instance
|
|
bot: build repo:dev.eessi.io-riscv-2025.06-001 instance:eessi-bot-riscv for:arch=riscv64/generic |
|
New job on instance
|
Add check for the existence of the
EESSI_SITE_SOFTWARE_PATH. This is needed if we make this location configurable throughEESSI_SITE_SOFTWARE_PREFIXas is done in #232Edit: hmmm, this check was requested by @ocaisa . But now that I see the CI failing because the dir doesn't exist, I'm wonderig... this means that sites would have to precreate the dir, before they even set
EESSI_SITE_INSTALL=1, or the module will just flat-out fail to load. Is that what we want? If that dir does not exist whenEESSI-extendis loaded, how bad is that? Won't EasyBuild just try to create it? It looks like it...