okay so! working on building a post-PR/pre-merge github hook that triggers our CI server to run the tests and notify whether the build passes or not...
... so that maintainers can look at PR's from outside contributors and make sure all is kosher before merging
BUT there's a rub!
the go-cd integration with github is very wonky. and we're finding ourselves diving into rabitholes debugging the plugin Java code
which seems like a trap!
so we're like: "hey! why are we using go-cd anyway if travis, jenkins, circle (or whomever)" have seamless integration with github as a main selling point
and we're like -- it makes sense that those services (which are targeted to open source projects) would be better at this than go-cd, which it targeted at consultant projects.
and this kind of integration is something we're gonna want to do a lot
so perhaps we should consider switching
the question is: (1) does "we should switch CI providers" sound like a reasonable hypothesis to be entertaining? and (2) what would be the shortest possible experiment we could run to test that hypothesis?
(we think the experiment should be about comparing time of debugging go-cd's integration plugin vs. time spent getting started with a new service.)
(and don't want to get sucked into reading 1,000 articles on different CI providers)
which i guess means we're also interested in: (3) does anyone have strong preferences between travis, jenkins, and circle?
re (1): I think that is a reasonable hypothesis. Given that any time you spend (possibly) making go-cd play nice with github is time you could spend on any of the actual goals of our project and setting up circle/travis/jenkins is probably shorter than fixing go-cd
experiment update: we've narrowed to travis v. circle, leaning travis b/c more prior art (akka/spray , facebook/react-native both use it), and have some specific tests to try running the build and inspecting the alerts set up to run first thing tomorrow