Honestly, the key is hosting. If we have a host for CI that runs the basic build steps, we can configure any solution to build all the changes on branches of a collection of repos on Github. Pretty much all the reasonable options have a status update script on GitHub, which integrates it quite nicely. (And therein might lie the rub. I think GitHub ties status updates to "push permission", which may be false for everyone on the main repo, since it's just a mirror.) But direct integration or no, we'd be able to go look at the results and even download the binary, install it on a test system and watch it go.
Now, that doesn't get us automatic builds from first-time or probably even very occasional contributors. But stick builds on the most frequent contributors' clones and we get 95% of the benefit without solving any of the actually hard problems. We'd need a host, though. On Tue, Mar 14, 2017 at 5:06 PM Leif Hedstrom <zw...@apache.org> wrote: > > > On Mar 13, 2017, at 8:44 AM, Chris Lemmons <alfic...@gmail.com> wrote: > > > > To me, the key features of CI are that a) it builds each branch > > automatically, b) notifies affected parties when all is not well, and c) > > manages the artefacts in a reasonable way. Additionally, we're a lot more > > useful when we're writing neat software and not spending out time > managing > > CI, so it should be as automatic as reasonable. We're using github for > PRs, > > so if it's at all possible to get automatic PR tagging with build > > information, that is greatly desirable. Knowing that the PR breaks the > > build prior to merging it can save quite a bit of time. :) > > > My $0.25: My experience is that making as much CI build / tests on pull > requests, *before* they are landed, gives the most bang for the buck. But > that might not work well for you, since you can’t use Github right? > > — leif > > > > > I've not used BuildBot, but it feels... svney? > > > > Jenkins can do all of the above, though basically all those features are > > plugins. There's a "build per branch" plugin that uses branches to > > automatically make builds. There's a variety of notifier plugins. There > are > > some artefact management plugins. There is a "build PRs" plugin that's > > specifically designed for GitHub. Jenkins isn't much on its own, but > > properly adorned with plugins, it can do most of what we'd want, I think. > > > > I've also had extensive experience with Bamboo, Atlassian's closed-source > > solution in the same suite as Jira. Bamboo is usable gratis for OSS in > the > > same way we currently use Apache Jira. > > > > Bamboo also has plugins, but the majority of it's features are good to go > > immediately. There's an automatic checkbox for "build per branch". The > > artefacts are managed fairly automatically, especially if you fill in the > > "build expiration" boxes. Notification is automatic and easy to > configure. > > It's got a (free) plugin for PR statuses. > > > > In any case, we'll need to manually configure the valid lists of > > contributors. For security reasons, we probably can't just run whatever > PR > > is created without any prior contact. :/ In Jenkins, this looks like > > maintaining a "white list" of legal contributors for a PR inside the PR > > plugin. In Bamboo, it looks like listing the committer forks as copied > > projects. Either way is fairly manageable. > > > > Jenkins and Bamboo both run on Java. So... no winner there. :) > > > > I think the major question is one of hosting. No matter what solution we > > use, we need a few cycles, a network interface, and a bit of disk space > to > > run it. The apache jenkins appears to have almost all the stuff we need. > It > > does not appear to have docker-compose, which we're leveraging fairly > > significantly at the moment. docker-compose, however, is Apache licensed, > > so we could theoretically ship it inside the repo. Not sure I like that > > option, though. We could also switch off of compose and put the relevant > > options into our build script directly. Not sure I like that option, > either. > > > > We'd have the most flexibility if we could get one or more companies to > > donate a publicly accessible host (or even theoretically, a build slave), > > assuming that doesn't break Apache's rules. The CI doesn't need a ton of > > gas, but the more oomph it has, the more granularly it can build and more > > aggressively we can test. > > > > On Sun, Mar 12, 2017 at 6:54 PM Eric Friedrich (efriedri) < > > efrie...@cisco.com> wrote: > > > > Hey All- > > I’d played around before with Travis CI for Continuous Integration > > builds, but never actually set it up for the public repo. > > > > I know some others on the list have tried out comparable services. Does > > anyone have experience or suggestions to share? > > > > Also, we can now get access to Apache Buildbot ( > > https://ci.apache.org/buildbot.html) and an Apache hosted Jenkins ( > > https://cwiki.apache.org/confluence/display/INFRA/Jenkins) > > > > I think Traffic Server has their own separate Jenkins server so they can > > hit more platforms, but with the latest build changes, pretty much all we > > require is access to a docker daemon > > > > —Eric > >
