search

Reed-CompBio / spras

Signaling Pathway Reconstruction Analysis Streamliner (SPRAS)
MIT License
11 stars 20 forks source link

Best practices for pushing images to the DockerHub organization #147

Open annaritz opened 7 months ago

annaritz commented 7 months ago

I just pushed a new image of random walk with restart to DockerHub under the reedcompbio organization. This image came from a branch in @Lyce24's forked SPRAS repo: https://github.com/Lyce24/spras/tree/RWR, and he is currently testing it before doing a pull request to merge RWR.

This is prone to some inconsistency - the current docker image in the reedcompbio organization is from a Dockerfile that is not in the SPRAS repo yet. On the other hand, we want the image to be associated with the reedcompbio organization so the code in the PR can be merged into SPRAS.

One option is to keep the docker image in the developer's Dockerhub account, and once the branch is merged then push the image to reedcompbio. However, then there are two images floating around of the same method -one in the developer's account and one on reedcompbio.

agitter commented 7 months ago

The workflow I have used is roughly the following. See what you think of this and make any suggestions. We can make this more prominent in the contributing guide if we like it.

  1. Contributor creates the Dockerfile in their SPRAS branch, builds the Docker image locally, and pushes it to their DockerHub account for development
  2. The new SPRAS wrapper function uses the Docker image from the contributor's DockerHub account for the initial implementation and pull request review
  3. One of the members of the DockerHub reedcompbio organization (me or @annaritz) builds the Docker image locally from the Dockerfile to test it and pushes it to the DockerHub reedcompbio organization with tags v1 and latest. They also populate minimal metadata on DockerHub.
  4. Before merging the pull request, the contributor switches the wrapper functions and GitHub Actions workflows to use the reedcompbio DockerHub image instead of the contributor's image and makes sure it is tagged v1

I'm not positive step 2 will still work after the registry configuration changes in #132. The Docker username or organization used to be hard coded.

I don't see a problem with having two copies of the image on DockerHub.