mine is neuman. Thanks! On Thu, Mar 16, 2017 at 10:11 AM, Bryan Call <[email protected]> wrote:
> I added you to the group: > bcall@minotaur:~$ list_appgroups.pl hudson-jobadmin | grep friede > friede > > What are the other two apache usernames? > > -Bryan > > > On Mar 14, 2017, at 5:29 PM, Eric Friedrich (efriedri) < > [email protected]> wrote: > > > > 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 < > 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 <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 <https://ci.apache.org/ > buildbot.html>) and an Apache hosted Jenkins ( > >>>> https://cwiki.apache.org/confluence/display/INFRA/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 > >>> > >>> > > > >
