Create a script to make both current binaries and one behind

[ldecicco-USGS]

Versions of R that is...
Not sure that's even possible. If it is, super.

[jordansread]

The old travis scripts (pre r support) may have some fruit for this if we are building on a VM or container

[ldecicco-USGS]

@jiwalker-usgs : dockah?

[jiwalker-usgs]

Docker is only going to help with Linux stuff. Since Linux pretty much just does source installs, you are probably out of luck. There might be ways to build binaries for other OSs in Linux, but probably not worth the hassle?

[ldecicco-USGS]

Booo

[jordansread]

but...you can have travis or appveyor build mac and windows binaries, and they have hooks for those artifacts. Is this a no-go route?

[ldecicco-USGS]

My faith in travis and appveyor is much less than yours I think.

[ldecicco-USGS]

Also, are you suggesting that the package maintainers have to set that up?

[jordansread]

no, not at all. I am suggesting we use that to build the gran binaries. If that is possible.

[ldecicco-USGS]

Well, go ahead and set up what you are trying to describe I guess.

It's not even my lack of faith in them...it's more...is that a legitimate use of those services? Don't they have time limits? Right now, we might not surpass it, but soon down the road. Also, size limits GLMr<\cough>?

It's one thing to use them to test the packages. It's another to use as a critical build element in our production service. Maybe it is something they plan for, I would just want to confirm/understand better before spending any effort going down that road.

[jordansread]

</cough> </cough> I will look into it to see if it is possible. If not, I will see what others would recommend for this kind of thing.

[jordansread]

@ldecicco-USGS looking into this, it seems that both appveyor and travis support secure keys for AWS with artifact uploads to S3 buckets.

I was having some trouble with my appveyor test build because of an unrelated issue, but here is the outcome of J Hollister's quickmapr build: https://ci.appveyor.com/project/jhollist/quickmapr/build/artifacts, which includes a windows binary. Then, using the S3 deploy in the yaml -
http://www.appveyor.com/docs/deployment/amazon-s3
with their secure variables: http://www.appveyor.com/docs/build-configuration#secure-variables
Similar exists for travis but the syntax is quite different.

I don't think I know enough about your current build system to know if this is a good solution or not. If we start paying for these services, it would be about $200/mo in support of USGS-R. Thoughts?

[jordansread]

Multiple versions of R for appveyor: krlmlr-archive/r-portable#4 and for travis: https://github.com/metacran/r-builder/blob/master/sample.travis.yml

[jordansread]

@ldecicco-USGS to switch your R version (for local builds), you can use Rswitch http://r.research.att.com/#other

Was able to roll back to R version 2.15.2 (2012-10-26) -- "Trick or Treat" :)

[jordansread]

Built win binary for powstreams: https://ci.appveyor.com/project/jread-usgs/powstreams/build/0.1.47/artifacts

[lawinslow]

Which R version is this? Can you do the other too?

[jordansread]

This is actually R.devel (3.3.0). We want to create a build matrix for oldrel, current, and devel re: krlmlr/r-appveyor#2, and pitch in on that PR

[lawinslow]

Ok, so you propose using the built artifacts coming from Appveyor and Travis for Windows and OS X builds, right? Thoughts on how to pull them all in?

[jordansread]

from above: "using the S3 deploy in the yaml -
http://www.appveyor.com/docs/deployment/amazon-s3
with their secure variables: http://www.appveyor.com/docs/build-configuration#secure-variables
Similar exists for travis but the syntax is quite different."
Thoughts on that @lawinslow ? this was one of the other things I wanted to talk about this week.

[lawinslow]

My thoughts are that this is generally a bit of a mess and that to accomplish this, we're going to have to get a bit dirty. @ldecicco-USGS has been dealing with a lot of this. Someone needs to take on the whole big picture here and start figuring out what pieces work well and what pieces we're missing. The pushing of artifacts should be easy, but there are a lot of other small bits that need to be worked out.

Here are a few issues I'm grappling with right now:

• How do we trigger the process on both platforms?
• Do we want every triggered build to push a new package-set? Or is there a good way to control if a triggered build uploads artifacts or not?
• What's the feedback mechanism if a package build fails? Is the appveyor/travis interface ok?
• On Travis, can we use the now supported R environment, or to be on Mac, do we need to stick to the older approach using objective-c?

[lawinslow]

@jread-usgs @eread-usgs (Mac people), what versions of R are supported for a Mac on CRAN? I just noticed today that only r-release is listed for Maverics. The must still support r-oldrel...

[jordansread]

Wow, that is surprising. I feel like that is a change relative to what was up on CRAN for R 3.1.

[lawinslow]

Something tells me they support 3.1, it just doesn't show up there, but who knows.

[jordansread]

You are right. just checked w/ 3.1, and it is there.