Closed cpauvert closed 11 months ago
I only maintain the dockerhub version. It's a GitHub action that pushes the latest container on every commit: Docker YAML The quay.io container is probably created downstream of the bioconda version of tracy.
Thanks for pointing out that executable containers are deprecated. Fine for me to add bash to the container. Should be fixed now: Dockerfile fix
Thanks @tobiasrausch for the quick answer and the quick fix! It works now on nextflow with the bash addition. However, I had to manually delete the previous latest image to force nextflow to update the docker container to the latest latest. Maybe in the future, fetching the github tags (like for the bioconda repository) could help fix the version. I have very limited experience in that regard but it seems that via the docker metadata action it is possible to automatically label the newly built docker before pushing to docker hub.
Added container tags for releases: https://hub.docker.com/r/geargenomics/tracy/tags
This is awesome, thanks @tobiasrausch
Hi @tobiasrausch Thanks for developing and maintaining
tracy
. I've just discovered your tool and started trying it out, especially within a workflow manager like nextflow.I noticed some differences between the docker containers of
tracy
that are made available to the community and I was wondering which one you were maintaining and would advise:The dockerhub version is the most up-to-date with respect to the repository (built on 2023-10-27), it is really small in size (~15Mb on disk) and blazing fast! However, there is no tags to track down the version of
tracy
, the working directory is/root
, which you need to look up in the Dockerfile.The quay.io version has tags, and a working directory at the
/
but it is way (2-5x) slower for no reason that I could point to. This version was built in May but with the most recent tag of the repository.One of the main differences between the two versions is that I can only use one of them within nextflow. There is no
bash
command in no bash command in the dockerhub version. This is an executable container, which is deprecated in workflow managers (see https://github.com/nextflow-io/nextflow/issues/529).This is unfortunate that the two versions of the containers do not agree as their combined pros would be awesome (tags, speed, small size, runnable in nextflow)!
Building the container using the Dockerfile in the repository create a container that is very similar to the one on dockerhub. However, with a small workaround there I could make the docker image be used by nextflow by adding
bash
to the alpine image via:Let me know how would you envision this moving forward with the continuous releases of docker images.
Best,