get git branchname

[sorelfitzgibbon]

I have found it's very easy to forget to edit the .env file with the current git branchname leading to confusing results in the output directories of the wrong branch. My solution has been to create the following submission script. Thoughts? Better way to do this?

#!/bin/bash
## Usage: sbatch --partition F16 --exclusive --mail-user [email protected] runNFtest.sh 
## Usage: sbatch --partition F32 --cpus-per-task 16 --mem 32G --mail-user [email protected] runNFtest.sh

## default tests (no args): 
##   1. all four tools with tumor/normal
##   2. mutect2 tumor only
##   3. mutect2 with two tumor samples (fails due to sample name issue)

if git branch --show-current 2>&1 | grep 'fatal' 
    then echo 'submit from within git repo (to get current branch)' ; exit 1
else
    branch=`git branch --show-current`
fi
export NFT_OUTPUT="/hot/software/pipeline/pipeline-call-sSNV/Nextflow/development/unreleased/$branch"
export NFT_TEMP="/hot/software/pipeline/pipeline-call-sSNV/Nextflow/development/unreleased/$branch"

nftest run
#nftest run a_mini-somaticsniper
#nftest run a_mini-strelka2
#nftest run a_mini-mutect2
#nftest run a_mini-muse
#nftest run a_mini-mutect2-multiple-samples
#nftest run a_mini_n2-mutect2-tumor-only

[zhuchcn]

Thanks for sharing your code! @sorelfitzgibbon I also don't like that the output file paths have to be updated everytime. Maybe we can add a variable in the .env file, for eaxmple NFT_OUTPUT_APPEND_BRNACH and when set to true, we will handle it in nftest to get the git branch name ad append it to the NFT_OUPUT variable. With that, we won't need to update it everyday. I'm also thinking if the .env gets more and more complicated, maybe we can write a wizzard cli to help users define thie .env file, with prompts of "Do you want to append git branch name to NFT_OUTPUT? Y/n". But that's probably a separate story.

[yashpatel6]

Thanks for sharing your code! @sorelfitzgibbon I also don't like that the output file paths have to be updated everytime. Maybe we can add a variable in the .env file, for eaxmple NFT_OUTPUT_APPEND_BRNACH and when set to true, we will handle it in nftest to get the git branch name ad append it to the NFT_OUPUT variable. With that, we won't need to update it everyday.

I disagree on this; while it may make sense with our development practices, NFTest is meant to be a general Nextflow testing framework that's not specifically catered to our development practices/standards. With that in mind, the tool shouldn't really be dealing with git branches (ex. pytest for Python doesn't deal with that sort of thing) or trying to become an interactive tool requiring prompts and user inputs.

[zhuchcn]

I agree with you about nftest should be general, but we also want to make our lifes easy, and that's why I suggested to parameterize this behaivor. Or we can use NFT_OUTPUT_APPEND_GIT_BRANCH to be more specific to git. Not using git? Sorry 🤷🏼‍♂️ In fact I initally thought NFT_OUTPUT also applies to what you said, very specific to our own development setting. Because my understand is a testing framework should check whether the output or returned value of a functionality matches with expectation, instead of saving them to a designated location. But nextflow pipelines are different from other programming languages, and to use, keeping the test output per develop cycle is important to us, and potentially other pipeline developers.

I might be a little over-thinking about the 'wizzard' thing. I was thinking about the vue-cli (https://cli.vuejs.org/guide/creating-a-project.html#vue-create) tool when I was typing the earlier reply. Vue-cli is a cli tool that helps you creates a project with command line interaction. That's of couse not essential to us.

[yashpatel6]

I'm still going to push back against bloating a general tool with custom options/support for super specific things that aren't generalizable where we actively refuse to support outside of our specific lab. NFT_OUTPUT is actually not specific to our development settings, it's a common functionality/usage in Nextflow pipelines even outside of our lab (ex. see nf-core pipelines that also use an output directory parameter).

While I agree that we should try to make our lives easier, adding custom options to general tools with ambiguous support isn't advised. Instead, if it's really a major problem that users forget to update the output path, we can develop tooling around NFTest itself for our specific use-case rather than adding to NFTest

[zhuchcn]

Don't get me wrong. I'm 100% in with the idea of public or eventually public tools should be general, as both you and Paul mentioned. And it's not my intention to suggest things that are specific to our own settings, which is something I'll never do.

And just want to clarify. Of couse pipelines need output directory. But a common testing framework usually won't care about where the output should be stored, and because nftest is a testing framework specific to nextflow, that's why output directory is essential.

So something being "specific" or "general" could be hard to tell sometimes. Why do you think the behaivor of NFTest to be able to append the git branch name is specific rather than genral? I personally think it's the opposite.

I like your idea of additional tooling around NFTest. Maybe this can be a upstream/downstream thing. But regardless, I think the discussion around specificity and genrality is going to be very valuable, not only for NFTest but also for our future software development.

[yashpatel6]

So something being "specific" or "general" could be hard to tell sometimes. Why do you think the behaivor of NFTest to be able to append the git branch name is specific rather than genral? I personally think it's the opposite.

I would consider it specific because it doesn't apply in a general sense outside of our lab, ex. other than within our lab, adding git branch to an output path isn't general practice that I'm aware of. Also, adding that behavior brings up questions of why we would only specifically support git and no other version control or other methods of segregating development, both of which would contribute to the feature being more specific than general.

I like your idea of additional tooling around NFTest. Maybe this can be a upstream/downstream thing. But regardless, I think the discussion around specificity and genrality is going to be very valuable, not only for NFTest but also for our future software development.

Definitely agree, the discussion of scope of tools/software is a valuable topic to discuss! We touched on this in the NF WG yesterday and settled on extending our submission script to support submission of NFTest jobs with any specific modifications we would want (including automatically appending git branch) since we'll generally be running tests through sbatch.

[pboutros]

I'm not paying close enough attention to offer a specific technical comment, but I'll say that philosophically Yash is expressing how I feel about it. We want to eat our own cooking, as it were, and we don't want to customize said cooking unnecessarily. I'll leave smarter minds to figure out the right solution for this specific case!