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. :)
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
