> On Mar 13, 2017, at 8:44 AM, Chris Lemmons <[email protected]> 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) < > [email protected]> 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
