Support using software-layer-scripts changes directly in software-layer

Right now, when we need to change something (e.g. a hook) in software-layer-scripts in order to fix a build in software-layer, the procedure is:

  • Introduce fix in software-layer-scripts
  • Add temporary EasyStack to software-layer-scripts
  • Do build on software-layer-scripts to prove the fix
  • Remove the EasyStack
  • (optionally, if deploy is required) Do build on software-layer-scripts again (if the fix requires a deploy, like the eb_hooks.py currently do)
  • (optionally, if deploy is required) Deploy on software-layer-scripts
  • Merge software-layer-scripts PR
  • Go back to software-layer and rebuild there
  • Deploy software-layer PR
  • Merge software-layer PR

This procedure is rather complex, but has been necessary since we split-off software-layer-scripts.

In the support meeting of 6 Jan 2026, we discussed an alternative approach:

  • Introduce fix in software-layer-scripts
  • Make software-layer use the feature branch with the fix (or probably even better: check out a particular commit, and define that commit in a file in software-layer)
  • Build software-layer PR
  • (optionally, if deploy is required) Build software-layer-scripts PR (note: this won't have any temporary EasyStacks being added/removed!)
  • (optionally, if deploy is required) Deploy software-layer-scripts PR
  • Merge software-layer-scripts PR
  • Deploy software-layer PR
  • Merge software-layer PR

We should have checks in place to guarantee that software-layer builds only get deployed if they used build scripts from software-layer-scripts that actually got merged into the main branch. We also need to make sure that all deployments in software-layer-scripts are done (this is already taken care of by the current hook checking that eb_hooks.py changes get deployed). This is discussed in #216 .

The second procedure means less complication & rebuilding, since the actual software builds to prove the fix only needs to be done in one repo (software-layer), and since those can then actually be deployed.

One caveat is that it requires that EESSI-install-software.sh uses eb_hooks.py from the cloned software-layer-scripts repository, instead of from e.g. /cvmfs/software.eessi.io/versions/2025.06/init/easybuild/eb_hooks.py. What we want to avoid is differences in behavior between running EESSI-extend locally, and running builds in software-layer. Of course, provided that the above CI's are in place that guarantee that

a) deployment can only be done after the associated software-layer-scripts PR is merged and b) merge of software-layer-scripts PR can only be done after eb_hooks.py updates are deployed

this essentially guarantees that synchronicity.

  • Requires a CI to be added that ensures deployment of scripts such as install_cuda_and_libraries.sh and link_nvidia_host_libraries.sh (or do we have that already?)
Edited by Caspar van Leeuwen