Running pipelines from a git-repo with a main.nf doesnt work

[ekageyama]

Bug report

Here is a minimal pipeline with a main.nf and a nextflow config inside a subdirectory
https://github.com/ekageyama/nextflow_sub/tree/main

Expected behavior and actual behavior

nextflow run https://github.com/ekageyama/nextflow_sub.git -main-script pipeline/main.nf

or

nextflow run https://github.com/ekageyama/nextflow_sub/pipeline/
should work

Program output

Can't find git repository config file -- Repository may be corrupted: /Users/kageyamj/.nextflow/assets/ekageyama/nextflow_sub`
Or

WARN: Cannot read project manifest -- Cause: Remote resource not found: https://api.github.com/repos/ekageyama/nextflow_sub/pipeline//contents/nextflow.config
Remote resource not found: https://api.github.com/repos/ekageyama/nextflow_sub/pipeline//contents/main.nf```

Environment

• Nextflow version: 24.04.4
• Java version: 22.0.2
• Operating system: macOS
• Bash version: zsh 5.9 (x86_64-apple-darwin23.0)

[bentsherman]

For the second case, I'm not sure if it's meant to work without the full path:

nextflow run https://github.com/ekageyama/nextflow_sub/pipeline/main.nf

For the first case, it's failing because Nextflow is looking for a main.nf in the repo root, but I'm not sure why. Here is an abbreviated stack trace:

nextflow.exception.AbortOperationException: Remote resource not found: https://api.github.com/repos/ekageyama/nextflow_sub/contents/main.nf
	at nextflow.scm.RepositoryProvider.checkResponse(RepositoryProvider.groovy:309)
	at nextflow.scm.RepositoryProvider.invokeBytes(RepositoryProvider.groovy:255)
	at nextflow.scm.RepositoryProvider.invoke(RepositoryProvider.groovy:238)
	at nextflow.scm.RepositoryProvider.memoizedMethodPriv$invokeAndParseResponseString(RepositoryProvider.groovy:380)
	at nextflow.scm.RepositoryProvider$_closure3.doCall(RepositoryProvider.groovy)
	at nextflow.scm.RepositoryProvider.invokeAndParseResponse(RepositoryProvider.groovy)
	at nextflow.scm.GithubRepositoryProvider.readBytes(GithubRepositoryProvider.groovy:116)
	at nextflow.scm.RepositoryProvider.validateFor(RepositoryProvider.groovy:438)
	at nextflow.scm.AssetManager.checkValidRemoteRepo(AssetManager.groovy:374)
	at nextflow.scm.AssetManager.download(AssetManager.groovy:591)
	at nextflow.cli.CmdRun.getScriptFile0(CmdRun.groovy:640)
	at nextflow.cli.CmdRun.getScriptFile(CmdRun.groovy:573)
	at nextflow.cli.CmdRun.run(CmdRun.groovy:327)
	at nextflow.cli.Launcher.run(Launcher.groovy:515)
	at nextflow.cli.Launcher.main(Launcher.groovy:675)
``

I wonder if the `-main-script` setting is not being propagated correctly when `AssetManager` calls `checkValidRemoteRepo()`

[jorgee]

It is working when we use the default hub.

nextflow run ekageyama/nextflow_sub/pipeline/main.nf

 N E X T F L O W   ~  version 25.10.0

Pulling ekageyama/nextflow_sub ...
 Already-up-to-date
Launching `https://github.com/ekageyama/nextflow_sub` [determined_brahmagupta] DSL2 - revision: b409fabb25 [main]

executor >  local (2)
[87/b7d869] convertToUppercase | 1 of 1 ✔
[44/5d48f2] addPrefix          | 1 of 1 ✔
Pipeline completed at: 2025-11-21T18:54:13.330720995+01:00
Execution status: SUCCESS

When providing the URL, it uses it as a repo path (not checking if it finishes with .nf/nxf). When not using the URL, it assumes Github provider that always uses two path parts as repo and the rest as the main script path. However, it depends on the provider.

It is also not forwarding the -main-script to AssetManager, but I think it could be easily forwarded.

[jorgee]

I have drafted a PR for supporting this case:
nextflow run https://github.com/ekageyama/nextflow_sub.git -main-script pipeline/main.nf
Also discussing why other alternatives are not suitable.