Updated Dockerfile for easier deployment and consistent builds

[olliecheng]

Hi,

This PR contains an updated Docker build process which I hope will become a supported and well-maintained deployment method for JAFFA.

It supports GitHub Actions for auto deployment, includes a slimmed down final run stage, and includes a fixed set of binaries and runtimes which mirror the settings recommended in the JAFFA wiki. This PR also includes a patch for the bpipe bug in ssadedin/bpipe#290, which is a randomly occurring issue which can present in both containers and native runs.

Improvements compared to existing approaches:

• It runs the most recent version of JAFFA, 2.4! Hurrah!
• Sensible binding defaults:
  • JAFFA files are all located at /JAFFA, so you can find e.g. JAFFA_assembly.groovy at the location /JAFFA/JAFFA_assembly.groovy
  • Reference files are expected at /ref
• An entrypoint which points to bpipe (so you can execute the command bpipe run <params> with docker run docker://ghcr.io/olliecheng/jaffa:latest <params>
• A GitHub Action for builds and uploads. An automated build and deployment can be started using the corresponding button in Actions (see https://github.com/olliecheng/JAFFA/actions)
• Separate build and run stages are used, reducing the filesize of the final image
• Bundled R 4.4.0 and OpenJDK 11 runtimes (this matches the default of the WEHI HPC)
• Dependencies are installed using install_linux64.sh instead of a package manager. This should ease maintainability in two ways. Firstly, this means that the Docker image uses the same fixed dependency versions as the native install method, eliminating any potential differences arising as a result of version mismatches. Secondly, this prevents any update to package manager repositories affecting key dependencies.
• No wrapper around bpipe run <groovy>. When running JAFFA through bioconda or its auto-built Docker image, the Conda distribution obscures the bpipe call around a wrapper which may be confusing to users: see Please provide a conda wrapper for jaffal, as for other jaffa functionality #74.

The main goal is to produce an image which can be easily updated in the future if JAFFA changes, with as minimal change to the Dockerfile as possible.

In my testing, I've observed that the output from the native and the Docker JAFFAL pipelines are identical when testing using the instructions and data provided in the wiki. For direct, assembly, and hybrid modes, I think that the output is unlikely to be identical due to randomness in bowtie2. However, the first 9 columns of JAFFA_results.csv are identical.

You can try out my build of version 2.4 at docker://ghcr.io/olliecheng/jaffa:latest.

[olliecheng]

I am also interested in writing documentation to the JAFFA wiki explaining how to use the Docker image, alongside the regular method. That way, users won't need to read the Dockerfile to understand where JAFFA expects the reference files to be located or where to find the pipeline files.