You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be vey useful if we had a recommended process for publishing the built package bundle on success. I don't think this necessarily means any extra code for r-travis, but it does need some discussion about conventions. Ideally, we'd end up with a standard way of publishing packages that me add a function to devtools which made getting a binary package from travis easy: install_travis("hadley/devtools"), install_travis("hadley/devtools@v1.4.1") etc.
Things to think about:
How should we doctor the DESCRIPTION to make it clear that travis built the file?
Where should we store the files? S3? Github pages? Github releases? It's probably sufficient to store only the most recent build for each branch
Once travis support windows and r-travis supports os x, where would we put binary files?
Ideally, the convention should be flexible enough that eventually I could add a binary argument to install_github(), install_bitbucket() etc. if other distributed build systems become available.
It would be vey useful if we had a recommended process for publishing the built package bundle on success. I don't think this necessarily means any extra code for r-travis, but it does need some discussion about conventions. Ideally, we'd end up with a standard way of publishing packages that me add a function to devtools which made getting a binary package from travis easy: install_travis("hadley/devtools")
, install_travis("hadley/devtools@v1.4.1")
etc.Things to think about:
binary
argument toinstall_github()
,install_bitbucket()
etc. if other distributed build systems become available.cc @romainfrancois
The text was updated successfully, but these errors were encountered: