Hi, I've been tweeking the universc module and found out that the nf-test was failing for singularity because

--writable-tmpfs

doesn't seems to work with

underlay

WARNING: Disabling --writable-tmpfs as it can't be used in conjunction with underlay

Hence the executable

/cellranger-3.0.2.9001/cellranger

cannot be modify and universc script fail. It does work with Docker using

--privileged

. What would be the prefered way to solve this ? I was thinking of maybe copying the

/cellranger

folder in a temporary writable file when the module execute (does work on singularity but need to overwrite the

PATH

).

Oof. I'll try to play with a bit, but I strongly recommend not messing with

containerOptions

if at all avoidable, and I wonder if it's really needed here. In some cases, what makes the most sense is building new trees with e.g. links, yes.

I think that

/cellranger-3.0.2.9001

should be in a place where it can be modify as it seems to be necessary for universc:

script running in /universc/launch_universc.sh...
SOURCE '/universc/universc' is an absolute symlink to '/universc/launch_universc.sh'
... script called from /universc
Running launch_universc.sh in '/universc'
Error: Trying to run Cell Ranger installed at /cellranger-3.0.2.9001/cellranger
launch_universc.sh can only run with Cell Ranger installed locally
Install Cell Ranger in a directory with write permissions such as /home/louis/local and export to the PATH
The following versions of Cell Ranger are found:
 cellranger: /cellranger-3.0.2.9001/cellranger /cellranger-3.0.2.9001/cellranger-cs/3.0.2.9001/bin/cellranger

Copy pasting the folder locally does solve the issue, but I'm not sure it's the best way to go.

cp -a /cellranger-3.0.2.9001 "$PWD/local/"
export PATH="$PWD/local/cellranger-3.0.2.9001:$PATH"

Compared to writable tmpfs, building a tree is definitely the way to go.

I'm not familiar with container, what does building a tree mean ?

For bad software that e.g. expects to have writable data files next to the binaries, one way of fixing it is having a wrapper that builds a structure where that can happen (here, that'd be in the task directory/pwd somewhere).

The following seems to work github.com/nf-core/modules/pull/12955 But I was thinking that maybe recreating the container and putting /cellranger and /universc in a writable location would be cleaner. Is it possible in singularity ?

That looks mostly good (I'm not sure if one needs a new copy or if just symlinks to stuff works as well).

Okay thanks for the explanation. Symlinks doesn't seems to work as far as I tested.

I suspect the runners for Codespaces has a lot more free space than our runners...

Yeah this seems to be too few for singularity .sif creation for this particular module, hence why nf-test was disable for singularity I guess. But this does now works for singularity and docker without privileged permission. It's a bit ugly but it works 😅 They might be a cleaner way to build the tree locally. What do you think ? github.com/nf-core/modules/pull/12955

Without knowing everything there, I think it looks good. (Setting

localmem

static seems odd, though?) The image is 5.2 Gbyte according to https://quay.io/repository/nf-core/universc?tab=tags, so any runner with less than 11 Gbyte free at start is probably doomed to fail. But if I read the action correctly, it should request a 40 Gbyte volume from runs-on?

Setting

localmem

static seems odd, though?

Sorry old test.

So I'm not sure what's going on/how come we get a 20 Gbyte runner with 17 used.

Don't really know. Most of the storage is taken by /usr 11Gb /opt 2.8Gb /home 1.9Gb and /var 2.7Gb So from the 38Gb allocated we go down to 20Gb available. We have 5Gb OCI cache data + 13Gb cache convertion (what I found on codespace) + 3.3 final SIF (so it exceed the 20Gb left by > 1Gb). Here are some debugg info

=== Disk ===
  Filesystem      Size  Used Avail Use% Mounted on
  /dev/nvme0n1p1   38G   18G   20G  48% /
  === Apptainer ===
  APPTAINER_CACHEDIR=/home/runner/_work/modules/modules/.singularity
  NXF_SINGULARITY_CACHEDIR=/home/runner/_work/modules/modules/.singularity
  NXF_SINGULARITY_LIBRARYDIR=/home/runner/_work/modules/modules/.singularity
  There are 0 container file(s) using 0.00 KiB and 0 oci blob file(s) using 0.00 KiB of space
  Total space used: 0.00 KiB
  === Large directories ===
  4.0K	/home/runner/.apptainer
  4.0K	/home/runner/.composer
  8.0K	/home/runner/.aws
  12K	/home/runner/.m2
  200K	/home/runner/.config
  796K	/home/runner/_diag
  18M	/home/runner/.nf-test
  21M	/home/runner/.cargo
  37M	/home/runner/.nextflow
  81M	/home/runner/bin
  175M	/home/runner/.dotnet
  355M	/home/runner/_work
  597M	/home/runner/externals
  602M	/home/runner/.rustup
  1.9G	/home/runner
  4.0K	/bin.usr-is-merged
  4.0K	/lib.usr-is-merged
  4.0K	/media
  4.0K	/mnt
  4.0K	/sbin.usr-is-merged
  4.0K	/srv
  16K	/lost+found
  760K	/imagegeneration
  6.1M	/tmp
  8.1M	/root
  9.5M	/etc
  16M	/runs-on
  1.9G	/home
  2.7G	/var
  2.8G	/opt
  11G	/usr
  18G	/


  4.0K	/usr/games
  4.0K	/usr/lib64
  15M	/usr/lib32
  90M	/usr/include
  94M	/usr/sbin
  171M	/usr/src
  398M	/usr/libexec
  1.1G	/usr/bin
  2.3G	/usr/local
  2.8G	/usr/lib
  3.7G	/usr/share
  11G	/usr

Ok, that's better (some run I checked had 17 of 20 used or so). But I'm not sure if there's any sane way of dealing with such a bad container (but at least you get zsh setups in it).

I have to admit I don't know how to do that, but I'll take a look.

I think that'd require assistance from someone with quay access.

I do have but never did before. The idea is to pull the container once with apptainer/singularity. It's converted to .sif and then push this new image with a different name to quay.io/nf-core.

You can use the same repo, just a different tag as far as I know.

I did solve the issue. The module now works with docker and singularity but as it needs oras:// protocole nf-core linting fails.

Not that I know of. But linting failing sounds like a bug.

I will ask if we can force merge with oras.

👍 (there seems to be a number of uses of

oras

urls already, but if one thinks it's wrong, that's not really a good reason to do more of the wrong thing, but here I don't see any alternative.)