Re: Public CI Builds for Traffic Control

[Leif Hedstrom]

> On Mar 14, 2017, at 6:15 PM, Chris Lemmons  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.


So, we do not have the Jenkins master have “write permission” into the Github 
repo. I asked Infra before, and they said no, but I’ll try again.

However, things can still work reasonably well, since any registered Github 
accounts is able to comment on a PR / issue. So, no, we can’t set labels etc. 
automatically from the Jenkins master, but we get pretty good feedback on what 
happens with the builds. See e.g.

https://github.com/apache/trafficserver/pull/1581 



Cheers,

— leif

> 
> 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  wrote:
> 
>> 
>>> On Mar 13, 2017, at 8:44 AM, Chris Lemmons  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 

Re: Public CI Builds for Traffic Control

[Eric Friedrich (efriedri)]

Phil or Bryan-
  Could one of you please set me, Chris and Neuman up with accounts on the ASF 
Jenkins?
   (I am fri...@apache.org 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 
> 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 
> wrote:


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

Re: Github "Backport" Label

[Eric Friedrich (efriedri)]

The answer from INFRA- is that we cannot apply labels since we don’t have write 
access to the repo. Its a side effect of being a git mirror. 

I guess Traffic Server and their shiny Git-Dual setup has some bells and 
whistles we can’t use yet

—Eric

> On Mar 14, 2017, at 9:51 AM, Durfey, Ryan  wrote:
> 
> Starting a wiki page on pull requests guidance to document information like 
> this.
> 
> https://cwiki.apache.org/confluence/display/TC/Github+Pull+Request+Guidance
> 
> Ryan Durfey M | 303-524-5099
> 
> 
> From: "Eric Friedrich (efriedri)" 
> Reply-To: "dev@trafficcontrol.incubator.apache.org" 
> 
> Date: Monday, March 13, 2017 at 8:09 PM
> To: "dev@trafficcontrol.incubator.apache.org" 
> 
> Subject: Re: Github "Backport" Label
> 
> I opened an INFRA- JIRA and asked them to create it.
> 
> Why no one can apply labels, I don’t know…
> 
> —Eric
> 
> On Mar 13, 2017, at 10:07 PM, Jeremy Mitchell 
> > wrote:
> Actually, I'm a bit surprised you were even able to create the 'backport'
> label - https://github.com/apache/incubator-trafficcontrol/labels
> how did you do that? please tell. :)
> On Mon, Mar 13, 2017 at 7:59 PM, Jeremy Mitchell 
> >
> wrote:
> I didn't know we could create labels and apply them. If so, I think this
> would be fantastic...but like Dave, I don't see how to do it. :(
> On Mon, Mar 13, 2017 at 7:57 AM, Phil Sorber 
> > wrote:
> You can also search on the branch base. Something like: "is:pr is:open
> base:2.0.x"
> On Mon, Mar 13, 2017 at 7:55 AM Dave Neuman 
> > wrote:
> I see the label, but I don't see a way to add the label to existing PRs.
> On Sun, Mar 12, 2017 at 8:38 PM, Eric Friedrich (efriedri) <
> efrie...@cisco.com> wrote:
> I created a new label in Github called “backport”.
> Please tag any PRs with this label to make them easier to find.
> —Eric
> 
> 

Re: Public CI Builds for Traffic Control

[Chris Lemmons]

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  wrote:

>
> > On Mar 13, 2017, at 8:44 AM, Chris Lemmons  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 (
> > 

Re: Public CI Builds for Traffic Control

[Leif Hedstrom]

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

Re: Github "Backport" Label

[Durfey, Ryan]

Starting a wiki page on pull requests guidance to document information like 
this.

https://cwiki.apache.org/confluence/display/TC/Github+Pull+Request+Guidance

Ryan Durfey M | 303-524-5099


From: "Eric Friedrich (efriedri)" 
Reply-To: "dev@trafficcontrol.incubator.apache.org" 

Date: Monday, March 13, 2017 at 8:09 PM
To: "dev@trafficcontrol.incubator.apache.org" 

Subject: Re: Github "Backport" Label

I opened an INFRA- JIRA and asked them to create it.

Why no one can apply labels, I don’t know…

—Eric

On Mar 13, 2017, at 10:07 PM, Jeremy Mitchell 
> wrote:
Actually, I'm a bit surprised you were even able to create the 'backport'
label - https://github.com/apache/incubator-trafficcontrol/labels
how did you do that? please tell. :)
On Mon, Mar 13, 2017 at 7:59 PM, Jeremy Mitchell 
>
wrote:
I didn't know we could create labels and apply them. If so, I think this
would be fantastic...but like Dave, I don't see how to do it. :(
On Mon, Mar 13, 2017 at 7:57 AM, Phil Sorber 
> wrote:
You can also search on the branch base. Something like: "is:pr is:open
base:2.0.x"
On Mon, Mar 13, 2017 at 7:55 AM Dave Neuman 
> wrote:
I see the label, but I don't see a way to add the label to existing PRs.
On Sun, Mar 12, 2017 at 8:38 PM, Eric Friedrich (efriedri) <
efrie...@cisco.com> wrote:
I created a new label in Github called “backport”.
Please tag any PRs with this label to make them easier to find.
—Eric