search

Rblp / Rblpapi

R package interfacing the Bloomberg API from https://www.bloomberglabs.com/api/
Other
166 stars 75 forks source link

Enable GitHub Actions for CI #322

Closed eddelbuettel closed 3 years ago

eddelbuettel commented 3 years ago

Travis had a change of ownership, and is less generous with credits. Under my handle I cannot run CI anymore.

Many projects are migrating (or have already migrated) to GitHub Actions. I have a setup I call r-ci that is functionally equivalent to what we do now (and can in fact run at multiple CI backends, see the r-ci website and/or a recent-ish blog post (and video with demo) about it.

I could add that pretty easily if we all feel it adds value. Travis CI would remain and run if/when we can. We still have of course the overarching issue that tests really need a backend to run against which we don't have have at the cloud-based CIs. However, CI runs just invoke what tests do anyway and don't add or remove anything...

johnlaing commented 3 years ago

I don't think we gain much from CI because, as you point out, we can't actually connect to Bloomberg. Feel free to add r-ci if you like, I certainly don't object, but the status quo is fine by me as well.

eddelbuettel commented 3 years ago

Thanks for the feedback. I think I did not word my proposal as efficiently as I could have. The suggestion is to

I happen to disagree with "does not buy us much". We were able to end discussions on PRs at the poorer end of the spectrum when they didn't even build the package without error. That adds value, and has zero cost.

Otherwise, sure. Code is mature, repo effectively in maintenance so it is not the most important thing in the world.

johnlaing commented 3 years ago

Sure - the package building is the lowest possible bar. That's the difference between gaining "not much" vs "not at all".

Adding GitHub Actions sounds good then. Is there anything Travis does(/did) that GitHub Actions can't? If not then is there a reason to keep both? I'd be fine with replacing Travis altogether. If that turns out to be a mistake, we could always resurrect it from commit history.

eddelbuettel commented 3 years ago

It is strictly a superset. It can do more, can be triggered cron alike, has support from many code snippets -- folks have gone fairly bonkers.

Personally, I like to keep it simple (see r-ci). I am also on the fence for deleting Travis. So far I always kept it around. In all repos under my name, nothing happens (as I have zero credits), in others as works as before (i.e. see RcppArmadillo in the RcppCore org a few days ago). I would suggest keeping it, but it isn't hard or fast. There is also a conig switch at Travis.

(Oh, and I think we may have missed their call to move everything from travis-ci.org to travis-ci.com or some such. Oh well.)

A few things will be nicer simply because I updated run.sh from r-ci relative to the previous one at my r-travis. That said, we could enable that just at Travis -- but then this really feels more and more like a dead tree rather than just branch (and I was resisting that very change earlier in the fall but am now mostly completely over at GH Actions plus some trials at Azure just for "hedging bets").

eddelbuettel commented 3 years ago

Whoops. I accidentally dropped that commit on master -- I will revert that and redo it in a branch in a little bit.

I can also clean up Travis. The current one simply points to an outdated release (trusty) which is easy to fix.