r5r
r5r copied to clipboard
ipeaGIT
Push to DockerHub?
There's now a Dockerfile in the r5r repo. It might be useful to set up a GH Actions workflow that would build a docker image and push it to dockerhub on each production release, so people don't have to get R and Java set up on their systems to use r5r.
Thanks for the suggestion, Matt. I talked to the team and we like the idea. However, none of us have experience with Docker or Dockerhub yet. It might take a while for us to find time to learn how to do this, but we are open for contributions!
I can work on this later this month. I don't have permission to add assignees but feel free to assign me.
Hi @mattwigway. I know you volunteered to work on this issue but I thought that playing around with the Dockerfile would be a nice way to get more knowledgeable about docker as a whole.
I updated the Dockerfile to install the stable release of {r5r}, instead of the dev version as it configured before, with some additional tags to install all dependencies and convert installation warnings to error, so the image building process breaks if {r5r} fails to install.
You mentioned pushing the image on every product release. Do you think this current approach suffices it? I don't know if we could stumble upon some caching issues with how the Dockerfile is configured today.
EDIT: You can check the image here. I haven't added any description whatsoever, that will come soon.
My initial thought was to continue to install from the git repo, and set up a GitHub action to automatically push a tagged image to DockerHub only on tagged releases. That way you could request image ipea/r5r:v0.3.0 or whatever and get a stable version. It's probably also worthwhile to download R5 during the setup process so it is included in the Docker image.
Matt
On Thu, Feb 18, 2021, 4:23 PM dhersz [email protected] wrote:
Hi @mattwigway https://github.com/mattwigway. I know you volunteered to work on this issue but I thought that playing around with the Dockerfile would be a nice way to get more knowledgeable about docker as a whole.
I updated the Dockerfile to install the stable release of {r5r}, instead of the dev version as it configured before, with some additional tags to install all dependencies and convert installation warnings to error, so the image building process breaks if {r5r} fails to install.
You mentioned pushing the image on every product release. Do you think this current approach suffices it? I don't know if we could stumble upon some caching issues with how the Dockerfile is configured today.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ipeaGIT/r5r/issues/143#issuecomment-781643567, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKNLVJCBBDCW6BTTN2XV3S7WALXANCNFSM4WTR2CAQ .
On further consideration, I think the approach described by @dhersz makes sense - that way everything is built from the canonical source on CRAN. We probably can't build the image with GitHub Actions in that case, but that's okay. I do think we should add a command to the Dockerfile that runs download_r5() so that the R5 jar is already available in the image - since the docker /usr/local is ephemeral, not doing this requires re-downloading R5 every time the docker image is run.
Hi @mattwigway. I also liked your idea of setting up an Action to build an image on every tag release. It looks like an elegant way of creating tagged images on Docker, but I still have to figure out how to do so, since I don't have much experience with GitHub Actions either. Still, allowing for the use of old versions of the package could lead to some troubles regarding the R5 version (i.e. version 0.1.0 doesn't work with current R5 version). So we'd at least have to specify which R5 version works with which r5r version, and ideally figure out a way of preventing one to download an incompatible R5 version with download_r5().
While we figure out how to (and if we want to) implement the above approach, I'll add the download_r5() command to the Dockerfile, as per your suggestion. Great idea, thanks!
Suggestion incorporated to Dockerfile in .
I'll still have a look at tag release GitHub Actions to make sure the image remains updated to {r5r} most recent versions.
For it to work with the current Dockerfile, however, I think the tag release must be created after CRAN approval, otherwise it will still resort to the old version (i.e. if the tag release is created just after the push, while CRAN is still reviewing the submission, the image would be built under a new tag name, but would still use the old version, as the most recent would yet to be available on CRAN).
(having said that, the new image is already available on dockerhub)
Yes, I'm not sure GitHub actions is compatible with CRAN approval. Maybe other CI options would be? I'm not sure if there's even anything automated in CRAN approval that we could hook into to trigger a build.
Re: r5 download, is there a 1:1 mapping between R5R version and R5 versions? If so, we could just burn the appropriate R5 version into the Docker image. If not, maybe that's something that should be considered - so people don't have to look at two version numbers in order to reproduce outputs.
On Mon, Feb 22, 2021, 9:43 AM dhersz [email protected] wrote:
Suggestion incorporated to Dockerfile in .
I'll still have a look at tag release GitHub Actions to make sure the image remains updated to {r5r} most recent versions.
For it to work with the current Dockerfile, however, I think the tag release must be created after CRAN approval, otherwise it will still resort to the old version (i.e. if the tag release is created just after the push, while CRAN is still reviewing the submission, the image would be built under a new tag name, but would still use the old version, as the most recent would yet to be available on CRAN).
(having said that, the new image is already available on dockerhub)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ipeaGIT/r5r/issues/143#issuecomment-783423603, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEKNLSA3N4H66BVZXHZNE3TAJUSBANCNFSM4WTR2CAQ .