Travis CI for R? | Yihui Xie | /en/2013/04/travis-ci-for-r/

yihui 2022-12-16 23:06:10

Travis CI for R? | Yihui Xie

https://yihui.org/en/2013/04/travis-ci-for-r/

10 Comments

giscus-bot 2022-12-16 23:06:10

Guest *Scott Chamberlain* @ 2013-04-07 07:50:04 originally posted:

Yes, completely agree that we can do better. I have not technical expertise in this area, but would even pay money to make a better version of CRAN. In the present world of technology, we don't really need real humans...

giscus-bot 2022-12-16 23:06:11

Guest *Markus Gesmann* @ 2013-04-07 08:20:35 originally posted:

Travis CI sounds similar to R-Forge. R-Forge offers online repositories and runs continuously build and check processes. What are the difference, apart from the version control software used?

yihui 2022-12-16 23:06:21

R-Forge is slow and often broken (from my impression). Users have to notify the admin that the system is broken now and then: https://r-forge.r-project.org/tracker/?group_id=34 It often hangs up for unknown reasons.

Travis CI has a limit of 20 minutes for each build. It is running on virtual machines, in which you have complete freedom as if you were a system admin, e.g. you can run sudo apt-get install. That means you do not need to request the real admin to install anything for you. You can decide which software packages to install and how to test your code.

There are a number of problems at the moment, though, e.g. it does not build Windows packages; it only builds and checks packages, but does not provide binaries to download. I need to think more about it.

Originally posted on 2013-04-08 00:12:41

giscus-bot 2022-12-16 23:06:24

Guest *M. Edward (Ed) Borasky* @ 2013-04-08 05:00:16 originally posted:

There's also Open Build Service (formerly openSUSE Build Service), which will build packages for most versions of Linux, at least the ones that use Debian or RPM package formats. Fedora also has some tools for turning CRAN packages into mostly-Fedora-compatible RPMs.

giscus-bot 2022-12-16 23:06:28

Guest *Charlie Sharpsteen* @ 2013-04-20 18:44:13 originally posted:

Accessing R-Forge requires the use of SVN. This requires package authors to maintain a bridge between whatever version control system they are most productive in and SVN. After maintaining such a bridge for four years, I can say that it is a pain in the ass and a terrible drain on time and energy.

The fundamental problem is that R-Forge does have a great CI system---but there is no way to decouple the CI from the project management system and use it as a standalone service.

giscus-bot 2022-12-16 23:06:12

Guest *Edwin de Jonge* @ 2013-04-07 09:03:29 originally posted:

+1, I agree that Travis CI would be very helpful for building and checking R packages.

However, I think that a successful build and check is not (always) equal to a stable release, such as a CRAN release. I think that a package maintainer should be able to differentiate to unstable/stable releases.

Maybe this can be accomplished using different branches (e.g. a "CRAN" branch).

yihui 2022-12-16 23:06:20

That is what Bioconductor does -- there are a devel branch and a stable branch. You can push as many changes as you want to the devel branch, and they will be checked against the devel version of R. The stable branch has a fixed release schedule -- if you do not manage to fix the errors before the release date, you are out.

Originally posted on 2013-04-07 20:27:39

giscus-bot 2022-12-16 23:06:23

Guest *jeroenooms* @ 2013-04-08 04:39:08 originally posted:

This idea, along with others, is further described in http://arxiv.org/abs/1303.2140

yihui 2022-12-16 23:06:25

Yes that is what Ian Fellows mentioned in the above comment :)

Originally posted on 2013-04-08 18:45:47

giscus-bot 2022-12-16 23:06:13

Guest *Nan Xiao* @ 2013-04-07 12:25:49 originally posted:

“Tho’ much is taken, much abides; and tho’

We are not now that strength which in old days

Moved earth and heaven; that which we are, we are;

One equal temper of heroic hearts,

Made weak by time and fate, but strong in will

To upload, to check, to pass, and not to automate.”

@nanxstats

giscus-bot 2022-12-16 23:06:14

Guest *Vincent Arel-Bundock* @ 2013-04-07 13:36:49 originally posted:

I think it's probably possible to do this already. With Python statsmodels, what we did was use the travis.yaml to install the necessary packages via apt-get, fake that we were in a different languages' environment (erlang), and then have our test script throw up a generic error when tests failed. I'm pretty sure the same approach can be replicated with R already since ubuntu (what the Travis machines run) has R in their repositories. See this file for example:

https://github.com/statsmodels/statsmodels/blob/master/.travis.yml

yihui 2022-12-16 23:06:19

That is really helpful information! Thanks a lot! I will give it a try.

Originally posted on 2013-04-07 20:14:10

giscus-bot 2022-12-16 23:06:15

Guest *Ian Fellows* @ 2013-04-07 17:59:31 originally posted:

Jeroen Ooms has some interesting ideas on CRAN versioning: http://arxiv.org/abs/1303.2140

giscus-bot 2022-12-16 23:06:16

Guest *karsten* @ 2013-04-07 22:15:06 originally posted:

disclsimer: I don't know Travis.

but ......

relying on gitbuh, means relying on a private enterprise to provide a critical infrastructure.

in science, we want redundancy and independence. the quasi-monopoly of github is quite the opposite of this.

there need to be independent mirrors, there needs to be review, there needs to be anti-IP stance. are you willing to bet the future of our beloved statistical system on the benevolence of a so,e company?

giscus-bot 2022-12-16 23:06:26

Guest *Charlie Sharpsteen* @ 2013-04-20 18:36:34 originally posted:

This "GitHub is a quasi-monopoly" sentiment betrays a lot of ignorance about how Git works. Just as the architecture of the Internet makes it difficult to censor information, the architecture of Git makes it difficult to monopolize access to code as each checkout of a repository is a full-fledged clone. GitHub enjoys a large userbase as a result of efforts spent on community-building and user empowerment.

It is very hard to be an abusive monopoly when your users can take their code and leave with a single command: git push --all [somewhere else].

giscus-bot 2022-12-16 23:06:17

Guest *M. Edward (Ed) Borasky* @ 2013-04-07 23:06:33 originally posted:

"the number of R packages is growing exponentially;" That's the problem that needs to be solved!

yihui 2022-12-16 23:06:22

I agree.

Originally posted on 2013-04-08 00:14:43

giscus-bot 2022-12-16 23:06:18

Guest *awws* @ 2013-04-08 10:04:22 originally posted:

Probably a stupid quesiton, but Travis makes use of test on the build to ensure the greater part of the integrity of packages (at least in the ruby community, which uses github heavily) using rspec, test::unit or Minitest. I'm not sure I've ever seen tests written for R packages. In fact, I'm not even sure what people use for testing in R packages (I've never written one, but keep on meaning to contribute though coding other stuff keeps me busy.).

And +1 for the idea of using any type of CI server to check stuff over from whatever repo you use.

yihui 2022-12-16 23:06:24

For R packages, you have R CMD check, which is a very verbose check of many things in the package even including the syntax of documentation. You can also write unit tests, and they will be run during R CMD check.

Originally posted on 2013-04-08 18:44:37

giscus-bot 2022-12-16 23:06:27

Guest *Charlie Sharpsteen* @ 2013-04-20 18:38:19 originally posted:

For R, the testthat package is pretty much an implementation of tools like Rspec:

https://github.com/hadley/test_that

giscus-bot 2022-12-16 23:06:19

Guest *Mark van der Loo* @ 2014-09-28 13:34:19 originally posted:

I don't really care what technology checks and builds my packages, whether its Travis CI or anything else. What would help me a lot is to have something like the equivalent of a CRAN server that builds my packages on all the platforms that CRAN supports, prior to CRAN submission. That includes solaris, windows, mac, and various linux flavours -- I'm not sure what is and isn't supported by Travis CI. I've ran into trouble a few times with different compilers on different systems, even though I make a point of staying true to the C99 standard. If such a 'pre-cran test server' would be available, I could solve problems possibly without having to bother the CRAN maintainers (who, by the way, have always been of great help to me) during the actual submit.

yihui 2022-12-16 23:06:29

Agreed. But CRAN does not seem to be interested in the idea of such a "test pool", although they have the perfect infrastructure. You either get blamed after submission, or you do not. There is no third choice. And they seem to like emails, which I absolutely hate. Things that ought to be automated are not automated, and this is the biggest problem of CRAN. Human time is expensive, and computer time is cheap.

Originally posted on 2014-10-12 05:28:16