nextflow-io / nextflow

A DSL for data-driven computational pipelines
http://nextflow.io
Apache License 2.0
2.61k stars 606 forks source link

Wave build with singularity results in Docker build, not Singularity build #5015

Closed marcodelapierre closed 1 month ago

marcodelapierre commented 1 month ago

Bug report

While runnings tests for https://github.com/nextflow-io/nextflow/issues/4999, I have noticed that, when triggering Wave builds using the Singularity engine during a Nextflow pipeline run, Wave ends up building a regular Docker image, not a Singularity image.
The pipeline run is fine.
However, this behaviour is in contrast with what Wave CLI provides, and with what we have documented in the recent blog post.

Expected behavior and actual behavior

Expected: as detailed in the recent Singularity blog post, the request of a Wave Singularity image through Nextflow would result in a native Singularity image build, which is then stored as ORAS artifact on the provided OCI repository.

Actual: a Docker build is triggered instead.

Steps to reproduce the problem

Use this extra config file, wave.config:

profiles {

  wave1 {
    wave.enabled = true
    wave.strategy = 'conda'
    wave.freeze = true
    wave.build.repository = "$WAVE_BUILD_REPO"
    apptainer.ociAutoPull = true
    singularity.ociAutoPull = true
    docker.enabled = true
    tower.accessToken = "$TOWER_ACCESS_TOKEN"
    tower.workspaceId = "$TOWER_WORKSPACE_ID"
  }
  wavesing1 {
    wave.enabled = true
    wave.strategy = 'conda'
    wave.freeze = true
    wave.build.repository = "$WAVE_BUILD_REPO"
    apptainer.ociAutoPull = true
    singularity.ociAutoPull = true
    singularity.enabled = true
    tower.accessToken = "$TOWER_ACCESS_TOKEN"
    tower.workspaceId = "$TOWER_WORKSPACE_ID"
  }

}

Docker run:

nextflow run nextflow-io/rnaseq-nf -c wave.config -profile wave1

Singularity run:

nextflow run nextflow-io/rnaseq-nf -c wave.config -profile wavesing1

Program output

Take for example the FASTQC process, inspection of the adopted container image reveals that the same Docker-native one is used in both runs:

# docker run
$ grep 'docker run ' work/dd/a29142c286869d6a7ceb7a5fc3fc06/.command.run 
    docker run -i --cpu-shares 1024 -e "NXF_TASK_WORKDIR" -v /home/ubuntu/rnaseq-nf:/home/ubuntu/rnaseq-nf -w "$NXF_TASK_WORKDIR" --name $NXF_BOXID quay.io/marcodelapierre/wavebuild:fastqc-0.12.1--2dbaa6a26c7d0ac6 /bin/bash -c "eval $(nxf_container_env); /bin/bash -ue /home/ubuntu/rnaseq-nf/work/dd/a29142c286869d6a7ceb7a5fc3fc06/.command.sh"

# singularity run
$ grep 'singularity exec ' work/72/65e01a255d078cdd460c8520b532ed/.command.run 
    set +u; env - PATH="$PATH" ${TMP:+SINGULARITYENV_TMP="$TMP"} ${TMPDIR:+SINGULARITYENV_TMPDIR="$TMPDIR"} ${NXF_TASK_WORKDIR:+SINGULARITYENV_NXF_TASK_WORKDIR="$NXF_TASK_WORKDIR"} singularity exec --no-home --pid -B /home/ubuntu/rnaseq-nf docker://quay.io/marcodelapierre/wavebuild:fastqc-0.12.1--2dbaa6a26c7d0ac6 /bin/bash -c "cd $NXF_TASK_WORKDIR; eval $(nxf_container_env); /bin/bash -ue /home/ubuntu/rnaseq-nf/work/72/65e01a255d078cdd460c8520b532ed/.command.sh"

In both cases in this example, image is quay.io/marcodelapierre/wavebuild:fastqc-0.12.1--2dbaa6a26c7d0ac6.

Environment

pditommaso commented 1 month ago

It's correct because ociAutoPull implies that Singularity pulls and convert the *docker* image

marcodelapierre commented 1 month ago

Oh makes sense, thanks for pointing out. I think the documentation needs to better clarify this point. Will make a PR soon.

[edit]: docs PR opened: https://github.com/nextflow-io/nextflow/pull/5024.