Updated the bowtie2 testing strategy: github.com/nf-core/modules/pull/12348 Main reason - getReads() from the nft-bam plugin led to merge marker linting conflicts in the QUAL column of bams. However, the github CI and my local testing repeatedly produced different hashes when using getReadsMD5(). I tried to figure out why but failed ( ping - @Nicolas Vannieuwkerke , potentially you have an idea? Happy to fix things accordingly)

What is present in your reads? It might be some floating point number difference between your local system and the CI?

That is a good question. The complete entry in the bam file, post samtools view/sort. I tried to get things as reproducible as possible (e.g setting missing seeds) but that didn't help. I didn't have that issue when using .getReads(5) and the earlier nft-bam version a few weeks ago. Not sure if one could also limit the getReadsMD5 to the first few reads?

Not directly in the plugin but you could paste the first five reads into the

listToMD5

function from the nft-utils plugin: nf-co.re/nft-utils#…

I like the idea, will give it a try. Also the getHeadersMD gave unstable hashes. If you prefer i can open an issue on the repo?

Could you first double check that the header isn't unstable itself? Headers usually contain file paths for commands used to generate the file and these are rarely stable

Sure, I will! Keep you in the loop but I think you are totally right, didn't think about the file paths... Not sure but is there a way to restrict the fields read in a bam() file? I bet, as you said there is something minor that causes the problem 🙂

You could read in the header and do a filter search on the returned list 😛 No way to do it natively in the plugin but doing the list filter should be pretty easy to do

Agree 🙂 I will look at it, and open a follow up PR for bowtie2 to get a more sophisticated testing reimplemented then