nextflow pull: unexpected behaviour after using -r

[ewels]

Bug report

After using -r with nextflow pull to pull a specific version of a pipeline, I would expect running nextflow pull a second time to check out the latest version of the code. Instead, it leaves the assets repo HEAD pointing to the previous -r tag.

I could imagine this causing problems for users who want to run a pipeline once with an old version of the pipeline code who then go back to using their "normal" command without the -r flag.

Expected behaviour

$ nextflow pull nf-core/rnaseq -r 1.1
Checking nf-core/rnaseq ...
done - revision: 1cd5ab733a [1.1]

$ nextflow pull nf-core/rnaseq
Checking nf-core/rnaseq ...
Already-up-to-date - revision: 37f260d360 [master]

Actual behaviour

$ nextflow pull nf-core/rnaseq -r 1.1
Checking nf-core/rnaseq ...
done - revision: 1cd5ab733a [1.1]

$ nextflow pull nf-core/rnaseq
Checking nf-core/rnaseq ...
done - revision: 1cd5ab733a [1.1]

Forcing the second command with an explicit -r master solves the issue, but this isn't ideal.

Steps to reproduce the problem

Pull an nf-core pipeline using nextflow pull. Then pull a specific (old) release using -r. Then pull it again without this.

Environment

$ nextflow -version

      N E X T F L O W
      version 19.09.0-edge build 5167
      created 16-09-2019 21:15 UTC (23:15 CEST)
      cite doi:10.1038/nbt.3820
      http://nextflow.io

$ java -version
java version "1.8.0_144"
Java(TM) SE Runtime Environment (build 1.8.0_144-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.14.6
BuildVersion:	18G95

[pditommaso]

The problem is that the -r option keeps the state because in practice what is doing is to check out the repo with that tag/branch, therefore all the following git ops will refer to that tag/branch.

[ewels]

Sure, I understand that. But I still think that most people would implicitly expect nextflow pull to get the latest version of a pipeline.

Would it be possible to default to -r master if -r is not specified? Or be one step cleverer and detect the default branch..?

[pditommaso]

As short term workaround, I think we could show a warning as for the run command

nextflow/modules/nextflow/src/main/groovy/nextflow/scm/AssetManager.groovy

Lines 873 to 878 in 55be076

	def current = getCurrentRevision()
	if( current != defaultBranch ) {
	if( !revision ) {
	throw new AbortOperationException("Project `$project` currently is sticked on revision: $current -- you need to specify explicitly a revision with the option `-r` to use it")
	}
	}

[ewels]

Yes, that would be great!

[thorellk]

We have the same issue so if you have a chance of implementing this, please do :)

[ewels]

Just had a quick look at the source code to see if I could prep a PR. But @pditommaso I'm a bit confused about where the defaultBranch variable comes from in your highlighted code block above. Should it not be manifest.getDefaultBranch() instead?

[pditommaso]

Sorry Phil, was missing this. In groovy defaultBranch is a shortcut for the method getDefaultBranch() that surprise is defined as

    String getDefaultBranch() {
        getManifest().getDefaultBranch()
    }

😄

[ewels]

🤯