let EESSI container script's run mode call apptainer exec instead of apptainer run

[bedroge]

eessi_container.sh --mode run expects a command or scripts, and then calls apptainer run <container> <command/scripts>. This is not correct:

$ apptainer run --help
Run the user-defined default command within a container

Usage:
  apptainer run [run options...] <container> [args...]

Description:
  This command will launch an Apptainer container and execute a runscript
  if one is defined for that container. The runscript is a metadata file within
  the container that contains shell commands. If the file is present (and
  executable) then this command will execute that file within the container
  automatically. All arguments following the container name will be passed
  directly to the runscript.

Though that still seems to work for containers that don't have a runscript defined, you will get unexpected behaviour for ones that do have a run script defined: it will not run the given command/script, but pass that as argument to the defined runscript.

Instead, it should actually call apptainer exec:

$ apptainer exec --help
Run a command within a container

Usage:
  apptainer exec [exec options...] <container> <command>

In order to fix it, I'm overriding run to exec before the container is started. It also (silently) accepts --mode exec. We may even want to completely rename the run mode to exec later on, and print a deprecation message? Would also require us to change it in several places.

[casparvl]

I think we should print some warning here that we've changed the behavior of this option to effectively exec. Even if we don't rely on any runscripts - and using run was effectively a mistake - this doesn't mean no one else used the eessi_container.sh with a runscript AND relied on its behaviour.

[casparvl]

Maybe we should even introduce a mode force-run or something, which this warning may then suggest as an alternative (i.e. "if you really wanted the old behavior, use eessi_container.sh --mode force-run" (which we then remove at some point if we want to ever deprecate the run-to-exec fallback)?

[bedroge]

Changed in 01aba0c. It now prints a warning message about the changed behaviour when --mode run is used, and it tells users to use --mode exec to silence that warning.

[casparvl]

Oh, and while I fully agree this should be 'fixed', I'm curious: did you hit issues because of this? If so, where?

[bedroge]

Oh, and while I fully agree this should be 'fixed', I'm curious: did you hit issues because of this? If so, where?

Yes, for the compat layer we have a container image that defines an entrypoint (https://github.com/EESSI/compatibility-layer/blob/main/Dockerfile.bootstrap-prefix-debian-13#L48) that acts as a runscript. Running that one with our eessi_container.sh script like eessi_container.sh --mode run -- ls will basically pass ls to the runscript.

[casparvl]

I think we should also adapt the CI to use the --mode exec, and maybe adapt the --mode run check at

software-layer-scripts/.github/workflows/test_eessi_container_script.yml

Line 82 in f37df6f

# test use of --mode run

to check for your warning.