Publishing travis artefacts

Not strictly about ropensci packages, but I suspect relevant to most.

I’m fishing around for ways of publishing travis (or appveyor) artefacts: binary packages in particular, but compiled vignettes, analyses, code etc. Previously I hacked together a solution for publishing to gh-pages on the project but that’s not ideal for a bunch of reasons (especially growing the size of the repo).

I’m thinking that with the rdropbox packages or similar for S3, google drive etc it could be possible to routinely save output, but am curious if anyone else has had similar thoughts and sketched out a solution.

I think this could be particularly useful for analyses (rather than packages) that are on travis.

1 Like

I’m guessing these docs pages you’ve already seen and are thinking of something different?


Yeah. Basically I’m trying to think what the lowest barrier to entry solution is, given the tools that a (say) biologist might have. People are unlikely to sign up for Amazon things just to collect output but most people have drive/dropbox/whatever. Ideally something like a package or a script so that all you’d have to add is a couple of lines or run something in the package and it’d set things up. Just thinking out loud really.

Sounds like a great idea; I agree that dropbox would be a lower barrier to
entry than S3 for most people., even though S3 is supported out-of-the-box
as it were. A straight-forward way to do this would be great.

Seems like this would just require a convenient implementation of the
dropbox API that could read credentials from environmental variables. I
think there’s some off-the-shelf versions for other languages, but not sure
if @Karthik 's rDrop is ready for prime-time? Seems like an httr
implementation could simplify some things there but I should really let
Karthik weigh in.

@richfitz what about deploying to github like this http://docs.travis-ci.com/user/deployment/releases/

I assume if they’re using travis, then they’re doing so for checking pushes to github, so low barrier to add this

@cboettig Good question Carl. It works just fine, but cannot go on CRAN because of a missing dependency. I suppose it is high time I moved it to httr and got it on CRAN, especially for use cases like these. Let me add that to my development calendar.

Sweet! I thought a bit more about this and how it could be cool if it worked.

Preamble: All of these deploy methods are going to require encrypted keys and generating these is a pain. There are things to authorise, keys to fetch, running the ruby travis script to encrypt the key, boilerplate to add to .travis.yml, and (perhaps) some configuration on the destination that will receive the payload. Most of this stuff is boring, error prone, and seems a good target for automation.

The user could install an ropensci package that contains helper scripts and do something along the lines of

collectr::add_dropbox()

which would print instructions for any non-scriptable things they need to do on dropbox, and do as much as possible in terms of fetching keys, running them through the encryption etc. It would add to .travis.yml a line to install the package (- ./travis.tool.sh install_github ropensci/collectr) and add an after_success line that just says something like Rscript -e collector::deploy_dropbox().

Then with the same interface we could support a variety of different backends while minimising the amount of unnecessary complication for users.