After installing a new OS I am trying to use best practices for software development and wanted to use the devcontainers for pipelines. However when I try to run my pipeline using the

test,docker

profile I get the following error:

Command error:
  bash: .command.run: No such file or directory

Anyone any idea of what is going wrong here?

Does binding

-v /etc/passwd:/etc/passwd:ro -v /etc/shadow:/etc/shadow:ro -v /etc/group:/etc/group:ro

those help in your dev container setup?

does not seem to work 😕

Can you check who the pipeline is being run as, and which user is writing the work directories?

All of it is the

root

user

That's what the files above are supposed to do for the dev container I think, but I'm not sure if I'm missing something

It might be a Nextflow bug? Somehow it doesn't run in the right location

That happened with singularity when the project/home directory wasn't mounted and it silently tried to run in the root of the container.

That could be the case, it thinks it's running in

/workspaces/smallvariants

but it can't find that absolute path

Pixi just works nicer

I'll setup pixi then 🙂 thanks for the help!

I haven't written a plugin since they introduced the plugin feature.

Thanks! I think it's something in the way gradle tries to use Java. It doesn't recognize the

JAVA_HOME

env variable correctly resulting in the following error:

Execution failed for task ':compileGroovy'.
> Error while evaluating property 'groovyCompilerJvmVersion' of task ':compileGroovy'.
   > Failed to query the value of task ':compileGroovy' property 'javaLauncher'.
      > Cannot find a Java installation on your machine (Linux 7.0.3-arch1-2 amd64) matching: {languageVersion=21, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}. Toolchain auto-provisioning is not enabled.

Did you echo if

JAVA_HOME

is set? Otherwise you can make an entry for it in the activation section

yes it's set to the correct location:

$ echo $JAVA_HOME
/home/nvnieuwk/Documents/nextflow/plugins/nf-cmgg/.pixi/envs/default/lib/jvm

OK. I got the same error as you:

make assemble
./gradlew assemble
> Task :compileGroovy FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileGroovy'.
> Error while evaluating property 'groovyCompilerJvmVersion' of task ':compileGroovy'.
   > Failed to query the value of task ':compileGroovy' property 'javaLauncher'.
      > Cannot find a Java installation on your machine (Mac OS X 26.4.1 aarch64) matching: {languageVersion=21, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}. Toolchain download repositories have not been configured.

* Try:
> Learn more about toolchain auto-detection and auto-provisioning at <https://docs.gradle.org/8.14/userguide/toolchains.html#sec:auto_detection>.
> Learn more about toolchain repositories at <https://docs.gradle.org/8.14/userguide/toolchains.html#sub:download_repositories>.
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at <https://help.gradle.org>.

BUILD FAILED in 846ms
1 actionable task: 1 executed
make: *** [assemble] Error 1

I managed to get it working by directly installing gradle in the pixi env instead of relying on the jar available in the plugin template

Hmm. That didn't solve it for me.

pixi add gradle

, exiting the env, and restarting it, doesn't work for me. I still get the same error

The makefile uses the

./gradlew

executable. Can you try

gradle assemble

?

It's working for you. I need to get on with something else

Allright, thanks for the help 😛

A bit late to the thread but may be worth trying: You could try mounting your host machine path to the matching path inside the container:

"workspaceFolder": "${localWorkspaceFolder}",
"workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind"

It sounds a like maybe nextflow couldn't find the workdir.

After adding that change this popup shows up:

Late to the thread, but just to expand, we hit the same

.command.run: No such file or directory

on the Nextflow training repo. @Julian Flesch is on the right track.

docker-outside-of-docker

mounts the host's Docker socket. So when Nextflow runs

docker run -v /workspaces/smallvariants/work/...

, it's the host daemon doing the bind, and the host has no

/workspaces/smallvariants

(that path only exists inside the devcontainer). The mount silently fails, the task container starts with no workdir, and bash can't find

.command.run

. Fix: make the in-container path match the host path so Docker resolves it either way.

"workspaceFolder": "${localWorkspaceFolder}",
"workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind"

That's what we do in

.devcontainer/local-dev/devcontainer.json

on

nextflow-io/training

, which is an alternate for folks not using Codespaces. Codespaces gets away without it because GitHub controls both sides and

/workspaces/<repo>

agrees. About the popup, workspaceMount is locked in at container creation. You need

Dev Containers: Rebuild Container

, not a restart. Ref: https://github.com/nextflow-io/training/blob/master/.devcontainer/local-dev/devcontainer.json

This is very interesting! Thanks for this, I'll give it another go next week 🙂