CI: Add small exec of fq, bam and cram

[keiranmraine]

Found a very small syntax error in the cram flow. Running on a very small dataset should be possible on travis for each. Ideally we want to build the package and then run parallel exec for each type of input/output option set, see here for travis docs on build stages.

fastq - input fastq, output bam + bai + test mmqc
bam - input bam, output bam + csi
cram - input cram, output cram

Data sets should be included in repo but as ref and BWA indexes needed will need to construct something by hand.

[mcast]

Relationship to CImon: currently CImon expects the extra test code and pointers to data to be outside the tested project / inside CImon, but this was a convenience for easy project start... not a design criterion.

Would it be good to permit "extra" test code to be included the project repository, so they're not artificially separated when they don't need to be? In some standard way a bit like the setup.sh, maybe .CImon.yml or big-tests.yml?

(CImon is an internal CI project for private/large data + heavy compute)

[keiranmraine]

@mcast , the about is related to checking execution paths rather than actually testing the result of a large scale analysis. I'm happy to have a .CImon.yml if it is of use to CImon but I would still want these tiny checks running on travis.

I see out CI-mon code being useful for testing features but it's going to be quite heavyweight when it comes to a hotfix. As soon as I get a minute I'll try incorporating PCAP/bwa_mem.pl into CImon but still waiting for a 'docs complete' from @drjsanger

[mcast]

Thanks for the explanation - the small or tiny size of these cases had escaped me, I was thinking of crams being constrained by Git(Hub) size.

Heavyweight tests are always going to interfere with CI flow, but this isn't helped by (I think... haven't checked) GitHub & Gitlab both having the notion that any commit will be tested in just one CI tool, i.e. CImon couldn't post a second test status on the same commit.

[keiranmraine]

If we changed to the model of hosting all the repos internally on GitLab, after internal CI (large) squash and push to GitHub there's a lot we can do... but I don't see this being a rapid switchover as accepting external PRs will become challenging.