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

Add support for testing R code to travis #1549

Closed
craigcitro opened this Issue Oct 26, 2013 · 16 comments

Comments

Projects
None yet
6 participants
@craigcitro
Member

craigcitro commented Oct 26, 2013

hi all,

i'd like to find out what it would take to make R a first-class citizen for travis. i recently created a repo with some terribly lowbrow scripts for testing out R on travis -- we're still working through details to streamline how we'd like things to work, but it definitely seems like there's interest.

i've got a bunch of questions:

  • is there any sort of "official" process for adding a new language?
  • should I start by converting everything to a chef cookbook and sending you a pull request here?
  • clearly i'll ultimately need to send PRs for a cookbook and some docs; are there other bits i'm not thinking of?
  • is there a CLA?
  • the readme for travis-cookbooks points to travis-boxes, which has a giant DEPRECATED note at the top; is there a replacement?

thanks!

@sarahhodne

This comment has been minimized.

Show comment
Hide comment
@sarahhodne

sarahhodne Oct 26, 2013

Contributor

Is there any sort of “official” process for adding a new language?

No, not really. This is pretty much it. There are two main things that we need for first-class support for a language: Adding the language to travis-build and adding cookbooks to travis-cookbooks. travis-build includes information on how to build the project by default, and some settings to make this easier, and the cookbooks have information on what should be preinstalled.

Should I start by converting everything to a chef cookbook […]?

That would be a good place to start, but before you put too much effort into it I'd love to hear what someone else on the (Travis) team says about adding another language. (/cc @joshk since you maintain the images right now).

Clearly I'll ultimately need to send PRs for a cookbook and some docs; are there other bits I'm not thining of?

  • Cookbooks for everything that needs to be preinstalled on the VMs
  • Travis Build class containing information on how to run R builds.
  • Documentation page for language.

Is there a CLA?

Nope!

The readme for travis-cookbooks points to travis-boxes, which has a giant DEPRECATED note at the top; is there a replacement?

Travis Images is probably what you're looking for.

Contributor

sarahhodne commented Oct 26, 2013

Is there any sort of “official” process for adding a new language?

No, not really. This is pretty much it. There are two main things that we need for first-class support for a language: Adding the language to travis-build and adding cookbooks to travis-cookbooks. travis-build includes information on how to build the project by default, and some settings to make this easier, and the cookbooks have information on what should be preinstalled.

Should I start by converting everything to a chef cookbook […]?

That would be a good place to start, but before you put too much effort into it I'd love to hear what someone else on the (Travis) team says about adding another language. (/cc @joshk since you maintain the images right now).

Clearly I'll ultimately need to send PRs for a cookbook and some docs; are there other bits I'm not thining of?

  • Cookbooks for everything that needs to be preinstalled on the VMs
  • Travis Build class containing information on how to run R builds.
  • Documentation page for language.

Is there a CLA?

Nope!

The readme for travis-cookbooks points to travis-boxes, which has a giant DEPRECATED note at the top; is there a replacement?

Travis Images is probably what you're looking for.

@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro Oct 31, 2013

Member

@joshk, any thoughts?

Member

craigcitro commented Oct 31, 2013

@joshk, any thoughts?

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Nov 1, 2013

Member

I am interested in us adding R, maybe starting with Travis Build changes first to see if we should make cookbook changes or have travis-build install what it needs to on each run.

Sound good?

On 31/10/2013, at 9:12 pm, Craig Citro notifications@github.com wrote:

@joshk, any thoughts?


Reply to this email directly or view it on GitHub.

Member

joshk commented Nov 1, 2013

I am interested in us adding R, maybe starting with Travis Build changes first to see if we should make cookbook changes or have travis-build install what it needs to on each run.

Sound good?

On 31/10/2013, at 9:12 pm, Craig Citro notifications@github.com wrote:

@joshk, any thoughts?


Reply to this email directly or view it on GitHub.

@krlmlr

This comment has been minimized.

Show comment
Hide comment
@krlmlr

krlmlr Nov 1, 2013

Several R packages are already tested with Travis CI: knitr, dplyr, plyr, tikzDevice, to name just a few. knitr has an integration test that installs LaTeX, it is also installed for each tikzDevice test. This requires several minutes for each run, these would be saved if an image that has it is available. Would it be possible to include LaTeX into one of the "default" cookbooks?

Almost everything else we need to install we basically install in the most recent version, so there's probably no benefit of packaging this into an image ==> travis-build.

krlmlr commented Nov 1, 2013

Several R packages are already tested with Travis CI: knitr, dplyr, plyr, tikzDevice, to name just a few. knitr has an integration test that installs LaTeX, it is also installed for each tikzDevice test. This requires several minutes for each run, these would be saved if an image that has it is available. Would it be possible to include LaTeX into one of the "default" cookbooks?

Almost everything else we need to install we basically install in the most recent version, so there's probably no benefit of packaging this into an image ==> travis-build.

@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro Nov 1, 2013

Member

@joshk yes, that sounds good. i'll start fiddling on my side and send a PR when i've got something going.

i'm actually on the other side of the fence from @krlmlr -- I do think there are several things it'd be nice to hook into travis-build.

Member

craigcitro commented Nov 1, 2013

@joshk yes, that sounds good. i'll start fiddling on my side and send a PR when i've got something going.

i'm actually on the other side of the fence from @krlmlr -- I do think there are several things it'd be nice to hook into travis-build.

@krlmlr

This comment has been minimized.

Show comment
Hide comment
@krlmlr

krlmlr Nov 1, 2013

@craigcitro: Let me restate that I'm 100% positive about providing a first-class language=r in travis-build. It's just that we perhaps don't need to put R and its packages into the Travis image because we install the freshest version anyway.

@joshk: How often are the images at travis-ci.org updated? If it's not too rare, a sensible default of R and packages might be good to have in the image anyway.

krlmlr commented Nov 1, 2013

@craigcitro: Let me restate that I'm 100% positive about providing a first-class language=r in travis-build. It's just that we perhaps don't need to put R and its packages into the Travis image because we install the freshest version anyway.

@joshk: How often are the images at travis-ci.org updated? If it's not too rare, a sensible default of R and packages might be good to have in the image anyway.

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Nov 1, 2013

Member

I think the first round of supporting R should be an R ‘builder’ in travis-build.

The second round is we can look at preinstalling some packages as needed, but updating VMs is using done monthly or bimonthly.

On 1/11/2013, at 3:15 pm, Kirill Müller notifications@github.com wrote:

@craigcitro: Let me restate that I'm 100% positive about providing a first-class language=r in travis-build. It's just that we perhaps don't need to put R and its packages into the Travis image because we install the freshest version anyway.

@joshk: How often are the images at travis-ci.org updated? If it's not too rare, a sensible default of R and packages might be good to have in the image anyway.


Reply to this email directly or view it on GitHub.

Member

joshk commented Nov 1, 2013

I think the first round of supporting R should be an R ‘builder’ in travis-build.

The second round is we can look at preinstalling some packages as needed, but updating VMs is using done monthly or bimonthly.

On 1/11/2013, at 3:15 pm, Kirill Müller notifications@github.com wrote:

@craigcitro: Let me restate that I'm 100% positive about providing a first-class language=r in travis-build. It's just that we perhaps don't need to put R and its packages into the Travis image because we install the freshest version anyway.

@joshk: How often are the images at travis-ci.org updated? If it's not too rare, a sensible default of R and packages might be good to have in the image anyway.


Reply to this email directly or view it on GitHub.

@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage May 2, 2014

Member

I'm closing this as the feature seems to have gotten stale. We may reconsider this in the future, and we'd be happy to accept contributions to travis-build too.

Member

roidrage commented May 2, 2014

I'm closing this as the feature seems to have gotten stale. We may reconsider this in the future, and we'd be happy to accept contributions to travis-build too.

@roidrage roidrage closed this May 2, 2014

@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro May 2, 2014

Member

i assume the thing to do is reopen once i've got a first travis-build PR ready?

Member

craigcitro commented May 2, 2014

i assume the thing to do is reopen once i've got a first travis-build PR ready?

@roidrage

This comment has been minimized.

Show comment
Hide comment
@roidrage

roidrage May 2, 2014

Member

Yeah, once we have something that we can consider shipping, we can keep this issue updated.

Member

roidrage commented May 2, 2014

Yeah, once we have something that we can consider shipping, we can keep this issue updated.

@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro Dec 20, 2014

Member

hi @roidrage and @joshk -- i'm finally getting a few cycles to work on this, so i wanted to reopen this with a few questions. the r-travis use seems to be going strong, so there's definitely interest.

  1. i saw the post about julia/C#/D support; i assume the right first step is to add support in travis-build along the same lines.
  2. relatedly, i see commentary in those PRs about avoiding sudo for docker -- this one gets a little difficult, because i need to install a few system packages (notably LaTeX). my inclination is to start by having a block of "clearly problematic on docker" commands up-front, and avoid sudo outside that. or is there a better way?
  3. related to docker, @eddelbuettel is already maintaining some docker images for R. being able to use those would remove a large amount of the need to sudo (especially since i could work with @eddelbuettel to upstream changes in that direction). should we talk about what it would mean to use custom docker images, or is that far enough out that we should just worry about it later?
Member

craigcitro commented Dec 20, 2014

hi @roidrage and @joshk -- i'm finally getting a few cycles to work on this, so i wanted to reopen this with a few questions. the r-travis use seems to be going strong, so there's definitely interest.

  1. i saw the post about julia/C#/D support; i assume the right first step is to add support in travis-build along the same lines.
  2. relatedly, i see commentary in those PRs about avoiding sudo for docker -- this one gets a little difficult, because i need to install a few system packages (notably LaTeX). my inclination is to start by having a block of "clearly problematic on docker" commands up-front, and avoid sudo outside that. or is there a better way?
  3. related to docker, @eddelbuettel is already maintaining some docker images for R. being able to use those would remove a large amount of the need to sudo (especially since i could work with @eddelbuettel to upstream changes in that direction). should we talk about what it would mean to use custom docker images, or is that far enough out that we should just worry about it later?
@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro Jan 30, 2015

Member

@joshk or @roidrage any thoughts?

Member

craigcitro commented Jan 30, 2015

@joshk or @roidrage any thoughts?

@eddelbuettel

This comment has been minimized.

Show comment
Hide comment
@eddelbuettel

eddelbuettel Jan 30, 2015

It's time. Otherwise people may just defect to CircleCI which from what I have been told allows deployment of custom Docker containers. Which would a cheap(er) way for us to test R code.

Travis is great as is, and used pretty widely by R folks. Making Travis easier and better can only help...

eddelbuettel commented Jan 30, 2015

It's time. Otherwise people may just defect to CircleCI which from what I have been told allows deployment of custom Docker containers. Which would a cheap(er) way for us to test R code.

Travis is great as is, and used pretty widely by R folks. Making Travis easier and better can only help...

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Feb 2, 2015

Member

@craigcitro thanks for taking the time in Dec to write up your last comment. As this was Xmas time this kinda fell into the abyss of time-off.

I would recommend getting started with travis-build and we can comment on a PR there and help where possible. Any start is a good start.

Sorry but we can't use Docker images yet. This is on our roadmap, but no ETA sorry.

Member

joshk commented Feb 2, 2015

@craigcitro thanks for taking the time in Dec to write up your last comment. As this was Xmas time this kinda fell into the abyss of time-off.

I would recommend getting started with travis-build and we can comment on a PR there and help where possible. Any start is a good start.

Sorry but we can't use Docker images yet. This is on our roadmap, but no ETA sorry.

@craigcitro

This comment has been minimized.

Show comment
Hide comment
@craigcitro

craigcitro Feb 2, 2015

Member

@joshk cool, sounds good. i've got a good chunk of a travis-build PR in the works, i'll send that out soon and go from there.

i'll be excited to simplify when docker images are available, but converting the existing code is definitely the fastest path forward anyway.

don't sweat the x-mas abyss: any time i had to work got eaten by 2yo & 5yo both getting sick. ;)

Member

craigcitro commented Feb 2, 2015

@joshk cool, sounds good. i've got a good chunk of a travis-build PR in the works, i'll send that out soon and go from there.

i'll be excited to simplify when docker images are available, but converting the existing code is definitely the fastest path forward anyway.

don't sweat the x-mas abyss: any time i had to work got eaten by 2yo & 5yo both getting sick. ;)

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Feb 2, 2015

Member

Awesome! We look forward to getting this merged in and live!

Have an awesome week!

Member

joshk commented Feb 2, 2015

Awesome! We look forward to getting this merged in and live!

Have an awesome week!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment