Phil or Bryan- Could one of you please set me, Chris and Neuman up with accounts on the ASF Jenkins? (I am [email protected]<mailto:[email protected]> btw)
This page https://cwiki.apache.org/confluence/display/INFRA/Jenkins says to ask a mentor or a PMC chair. Here are instructions for creating an account: https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount They only appear to have Ubuntu build slaves, but that shouldn’t be a problem with our docker build scripts. We can start to hack on it a bit in the background and plan to finish up or present something more at the summit in May? —Eric On Mar 14, 2017, at 8:15 PM, Chris Lemmons <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> wrote: On Mar 13, 2017, at 8:44 AM, Chris Lemmons <[email protected]<mailto:[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]<mailto:[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
