How do you test your internal packages (Travis, Jenkins, by hand?)



As an R user developing an internal package, what tools do you use for automated testing. Do you have access to continuous integration software like Jenkins and Travis? Would it be helpful if RStudio Package Manager ran automated tests? Do you use something else?

I'm dreaming of a (hosted) RStudio CI/CD

Our company CI software is Jenkins. It is planned to manage to use it with R development. But currently, it is not easy.
Do you have good ressources about case ?

Also, it would be nice if the product also provide integrated testing support. However, in big company as ours, there are already infrastructure for development purpose. We call it Development factory. It contains SonarQube, NEXUS, Jenkins and Gitlab.
Everything in the company must use this to go to production, it is kind of the standard.

It is why this is not easy to defend a full integrated product specific for R, when all other langage use the Factory.

It would then be better to work on integration and plugins to work with other product than completely include everything in the product itself. Even if it is awesome feature :wink:

What do you think ?


We were using Bamboo for a while, then BitBucket Pipelines. Now we're migrating to GitLab. We've had to create custom build / test scripts for each of those products that trigger on a pushed commit to an R package repository, run tests, build packages, and (if they passed) publish a dev or release build to our CRAN-alike repository.

I agree that ideally we'd want to continue to keep our git repos for R packages in the same place as our other code. Setting up the CRAN-alike repository was the easy part compared to getting the build / deploy process working.


@ajar This feedback is very helpful! Right now our plan is to allow RStudio Package Manager admins to point at certain Git repos, and then have RStudio Package Manager do all the work to watch for changes, run tests and builds, and push the artifacts into the CRAN-alike repositories it manages.

@cderv we are leaning in this direction as opposed to building plugins because:
a) there are many different potential plugins and integrations
b) some R users do not have access to build infrastructure

So out of the box we'd like to provide an integrated solution, but we realize this only further continues the "fracture" between R and your other tools, so we'd eventually also like to support integrations.


That is the dilemma ! I am currently tackling it on this topic because I am trying to make R a part of our company technology for good, as any other but all the awesome product for it are specific to R, so need more justification, and kind of the opposite message of "no worries, R is like other langage, we can put it into production".
however, considering the feature already in and those that will arrive, RSPM willl be more complete for R langage that any other tool for a specific language.

So, I understand the position and I have faith that RStudio will look after not increasing the "facture" too much. :slight_smile:

Thanks for the answer!