Skip to content
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

provide good docker image for pkg devel #106

Open
maxheld83 opened this issue May 1, 2019 · 5 comments
Open

provide good docker image for pkg devel #106

maxheld83 opened this issue May 1, 2019 · 5 comments
Labels
docker anything docker related pkg-dev stuff to help other package developers
Milestone

Comments

@maxheld83
Copy link
Owner

maxheld83 commented May 1, 2019

currently, ghactions (and all R actions contained therein) require that the user bring her own docker image, such as rocker/tidyverse, or whatever really.
This makes some sense for random rmd projects (etc.), where the compute environment might well be arbitrary.

It makes a lot less sense for CRAN-bound pkg-dev, where we're usually targeting a pretty well-defined compute environment (CRAN checks)

So it might make sense to default to / standardise on one docker image to run some of the pkg dev actions in. (And this is what the current focus of the project is).

The question is which image (in order of my descending, gut-feeling preference):

  1. one of the r-hub images, because these are (AFAIK?) closely replicating CRAN environments, are pretty slim and are concerned with pkg dev.
  2. One of the rocker images rocker/r-ver.
  3. One of the images maintained by RStudio as part of shinyapps.io or those used in rstudio launcher? (rely on rstudio images, as those used for rstudio launcher #96). (I know zilch about those).

@jimhester so my suggestion would be:

  • default to the r-hub images
  • ask you, or the slack channel which is most suitable.

This would imply:

  • We limit ghactions to one computing environment (say, debian), and leave the multi-platform testing to r-hub, for now.
  • We limit ghactions to one r version (say, release), and again, leave the multi-version testing to r-hub.
  • (We might later add an action to run multiple tests on r-hub as per add action for r-hub #71, but maybe not for every commit, but only on release candidates, or triggered by a special commit message or whatever, with all the results from r-hub pasted below the commit or PR).
@maxheld83 maxheld83 added docker anything docker related pkg-dev stuff to help other package developers labels May 1, 2019
@maxheld83
Copy link
Owner Author

naturally, this wouldn't apply for some of the "later" actions, such as styler::style_pkg()as in #103, because these can run on pretty much any well-suited docker image we like.

@jimhester
Copy link
Collaborator

I am not sure the RStudio ones actually exist currently, so I think relying on the R-hub ones seems like the best plan in the short term.

This was referenced May 1, 2019
@maxheld83
Copy link
Owner Author

ubuntu-gcc-release it is.

@maxheld83 maxheld83 added this to the Backlog milestone Jun 6, 2019
@maxheld83
Copy link
Owner Author

talked with **** (RStudio employee) yesterday and s/he suggested to take a look at

  • rstudio base img (which does some cool things) (this is open)
  • imgs used in launcher (apparently open)
  • and especially: imgs used for linux pkg building in rspm (apparently open)

Mariana-trench deep backlog, my favorite place for issues.

@maxheld83 maxheld83 reopened this Jun 6, 2019
@jimhester
Copy link
Collaborator

The repo is here FWIW https://github.com/rstudio/r-docker, they are versioned by OS and R version, so you can use rstudio/r-base:3.5-xenial for R 3.5 on xenial etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docker anything docker related pkg-dev stuff to help other package developers
Projects
None yet
Development

No branches or pull requests

2 participants