-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Push to DockerHub? #143
Comments
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 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 ***@***.***> 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
<#143 (comment)>, 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 While we figure out how to (and if we want to) implement the above approach, I'll add the |
Suggestion incorporated to Dockerfile in . I'll still have a look at tag release GitHub Actions to make sure the image remains updated to 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 ***@***.***> 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
<#143 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEKNLSA3N4H66BVZXHZNE3TAJUSBANCNFSM4WTR2CAQ>
.
|
Hello @dhersz and @mattwigway, I don't know if you guys still have this issue in mind (since it's been over 3 years), but maybe I have a solution for the Github Actions idea. I implemented a solution using Github Actions to build and push a Docker Image to Dockerhub upon a new tag release (here). In this case, each new tag will be pushed to Dockerhub as in my case (here). Older releases should probably be pushed manually, but after the implementation they should be updated automatically.
About that, maybe it's possible to create a second condition to allow build and push after CRAN approval (perhaps ChatGPT could help us on this one). I also don't have much experience with Github Actions, but I hope my solution could help to solve this issue. |
We could revisit this, but I think it's less relevant now - three years ago it was really difficult to get all the dependencies in place to run r5r, particularly on Mac. Nowadays with Temurin Java releases and a restructured dependency structure within R5 itself it's pretty painless in my experience. |
Check out this minimal example https://github.com/e-kotov/r5r-containerized which you can run with a click of a button in the repo: But also, look at the Dockerfile in the repo, it's very simple. Mine is a bit specific so that it runs in mybinder with all the repo contents. All you need for a working r5r Docker image is: FROM rocker/geospatial:4.4.0
# Install required packages
RUN R -e "remotes::install_github('e-kotov/rJavaEnv', force = TRUE, dependencies = TRUE)" && \
R -e "java_distr <- rJavaEnv::java_download(21); \
java_home <- rJavaEnv::java_install(java_distr); \
rJavaEnv::java_check_version_cmd(java_home); \
write(java_home, file = '/home/rstudio/java_home.txt')" && \
R -e "install.packages(c('r5r', 'accessibility', 'ggplot2', 'mapview', 'dplyr', 'h3jsr', 'sf'))"
# Switch to root user to be able to execute javareconf
USER root
RUN JAVA_HOME=$(cat /home/rstudio/java_home.txt) && \
export JAVA_HOME && \
echo "JAVA_HOME=$JAVA_HOME" && \
R CMD javareconf
USER rstudio
RUN rm /home/rstudio/java_home.txt After I implement the setting Java globally ( e-kotov/rJavaEnv#6 ) it will be even more reliable. Arguably, one can write a simple bash script to package certain Java 21 flavour into the Docker image instead of using |
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.
The text was updated successfully, but these errors were encountered: