[RFC] BuildHive for Jenkins on Jenkins Plugin CI
45 views
Skip to first unread message
Jesse Farinacci
May 18, 2012, 10:02:34 AM5/18/12
to jenkin...@googlegroups.com
Greetings,
Now that BuildHive has been announced, I think we should start using
it as the primary place for all Jenkins' plugin CI needs. It's kind of
a pain to manage these things for each plugin ourselves at JonJ -
http://ci.jenkins-ci.org
I think it also lends itself to us having to be more stable on
official JonJ since more and more plugin developers are depending on
it to build and test their plugins. This has an inverse effect that
JonJ can't be a place to test out more experimental work, as well as
other expectations about availability and stability.
In addition to being extremely easy to use, BuildHive also will
automatically test out pull requests and comment in the GitHub pull
request whether the change broke the build. This is totally awesome! I
think we may also be able to easily exploit Validated Merge
functionality which does roughly the same thing but without the hassle
of creating a pull request.
The proposal for discussion is to take a snapshot of all our plugin
jobs on ci.jenkins-ci.org as an archive. Then delete them from
ci.jenkins-ci.org. Utilize BuildHive as the canonical place for
Jenkins on Jenkins testing for plugins-only. Continue current usage of
ci.jenkins-ci.org for core and forked libs.
Comments?
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
Now that BuildHive has been announced, I think we should start using
it as the primary place for all Jenkins' plugin CI needs. It's kind of
a pain to manage these things for each plugin ourselves at JonJ -
http://ci.jenkins-ci.org
I think it also lends itself to us having to be more stable on
official JonJ since more and more plugin developers are depending on
it to build and test their plugins. This has an inverse effect that
JonJ can't be a place to test out more experimental work, as well as
other expectations about availability and stability.
In addition to being extremely easy to use, BuildHive also will
automatically test out pull requests and comment in the GitHub pull
request whether the change broke the build. This is totally awesome! I
think we may also be able to easily exploit Validated Merge
functionality which does roughly the same thing but without the hassle
of creating a pull request.
The proposal for discussion is to take a snapshot of all our plugin
jobs on ci.jenkins-ci.org as an archive. Then delete them from
ci.jenkins-ci.org. Utilize BuildHive as the canonical place for
Jenkins on Jenkins testing for plugins-only. Continue current usage of
ci.jenkins-ci.org for core and forked libs.
Comments?
-Jesse
--
There are 10 types of people in this world, those
that can read binary and those that can not.
nicolas de loof
May 18, 2012, 10:09:55 AM5/18/12
to jenkin...@googlegroups.com
What's the overlap with jenkins.ci.cloudbees.com we already proposed on governance meeting ?
please note we (cloudbees) can install the adequate plugins there to get pull-request checking as buildhive does.
2012/5/18 Jesse Farinacci <jie...@gmail.com>
Jesse Farinacci
May 18, 2012, 8:27:09 PM5/18/12
to jenkin...@googlegroups.com
Greetings,
On Fri, May 18, 2012 at 10:09 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> What's the overlap with jenkins.ci.cloudbees.com we already proposed on
> governance meeting ?
Well, it appears a complete one.
> please note we (cloudbees) can install the adequate plugins there to get
> pull-request checking as buildhive does.
Ok, well, as someone who is one of the primary caretakers of the JonJ
instance, and given the spat of recent problems which have been
plaguing the bleeding edge, I'd like to get the bulk of the builds off
the current JonJ instance at jenkins-ci.org. I don't have any
preference for buildhive.cloudbees.com vs jenkins.ci.cloudbees.com;
just that buildhive has a very nice manner in which to add new jobs.
And it ties nicely into GitHub organization support, so anyone with
the proper settings in that organization automatically gets to create
their own builds on the buildhive instance.
The other nice features of buildhive can apparently be added, as you say.
On Fri, May 18, 2012 at 10:09 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> What's the overlap with jenkins.ci.cloudbees.com we already proposed on
> governance meeting ?
> please note we (cloudbees) can install the adequate plugins there to get
> pull-request checking as buildhive does.
instance, and given the spat of recent problems which have been
plaguing the bleeding edge, I'd like to get the bulk of the builds off
the current JonJ instance at jenkins-ci.org. I don't have any
preference for buildhive.cloudbees.com vs jenkins.ci.cloudbees.com;
just that buildhive has a very nice manner in which to add new jobs.
And it ties nicely into GitHub organization support, so anyone with
the proper settings in that organization automatically gets to create
their own builds on the buildhive instance.
The other nice features of buildhive can apparently be added, as you say.
domi
May 21, 2012, 1:14:10 PM5/21/12
to jenkin...@googlegroups.com
the only thing I think we have to keep is: eat your own dogwood…
meaning: the plugins should be build with the latest Jenkins version available (just build with, not depend on it)
Without this, there would not be any testing of the latest version before a release.
/Domi
meaning: the plugins should be build with the latest Jenkins version available (just build with, not depend on it)
Without this, there would not be any testing of the latest version before a release.
/Domi
Jesse Farinacci
May 21, 2012, 1:28:20 PM5/21/12
to jenkin...@googlegroups.com
Greetings,
On Mon, May 21, 2012 at 1:14 PM, domi <do...@fortysix.ch> wrote:
> the only thing I think we have to keep is: eat your own dogwood…
> meaning: the plugins should be build with the latest Jenkins version available (just build with, not depend on it)
> Without this, there would not be any testing of the latest version before a release.
I agree about eating dogfood, and there will be many builds still on
the latest and greatest; just about 100 or so..
However, I don't see any advantage to a plugin being built with the
latest and greatest. Jenkins is mostly unrelated to the tools used to
build the plugins directly. I don't see anything specific to plugin
builds that isn't covered by building the core, e.g.
On Mon, May 21, 2012 at 1:14 PM, domi <do...@fortysix.ch> wrote:
> the only thing I think we have to keep is: eat your own dogwood…
> meaning: the plugins should be build with the latest Jenkins version available (just build with, not depend on it)
> Without this, there would not be any testing of the latest version before a release.
the latest and greatest; just about 100 or so..
However, I don't see any advantage to a plugin being built with the
latest and greatest. Jenkins is mostly unrelated to the tools used to
build the plugins directly. I don't see anything specific to plugin
builds that isn't covered by building the core, e.g.
Kohsuke Kawaguchi
May 22, 2012, 12:39:10 AM5/22/12
to jenkin...@googlegroups.com, Jesse Farinacci
On 05/18/2012 07:02 AM, Jesse Farinacci wrote:
> Greetings,
>
> Now that BuildHive has been announced, I think we should start using
> it as the primary place for all Jenkins' plugin CI needs. It's kind of
> a pain to manage these things for each plugin ourselves at JonJ -
> http://ci.jenkins-ci.org
>
> I think it also lends itself to us having to be more stable on
> official JonJ since more and more plugin developers are depending on
> it to build and test their plugins. This has an inverse effect that
> JonJ can't be a place to test out more experimental work, as well as
> other expectations about availability and stability.
>
> In addition to being extremely easy to use, BuildHive also will
> automatically test out pull requests and comment in the GitHub pull
> request whether the change broke the build. This is totally awesome! I
> think we may also be able to easily exploit Validated Merge
> functionality which does roughly the same thing but without the hassle
> of creating a pull request.
Yes, this is one of my TODO list. Allow committers to push changes to
> Greetings,
>
> Now that BuildHive has been announced, I think we should start using
> it as the primary place for all Jenkins' plugin CI needs. It's kind of
> a pain to manage these things for each plugin ourselves at JonJ -
> http://ci.jenkins-ci.org
>
> I think it also lends itself to us having to be more stable on
> official JonJ since more and more plugin developers are depending on
> it to build and test their plugins. This has an inverse effect that
> JonJ can't be a place to test out more experimental work, as well as
> other expectations about availability and stability.
>
> In addition to being extremely easy to use, BuildHive also will
> automatically test out pull requests and comment in the GitHub pull
> request whether the change broke the build. This is totally awesome! I
> think we may also be able to easily exploit Validated Merge
> functionality which does roughly the same thing but without the hassle
> of creating a pull request.
BuildHive, which gets pushed to GitHub when the push is tested and verified.
As Nicolas notes, we are also very happy to deploy all these individual
plugins on jenkins.ci.cloudbees.com (and that aligns well with our
overall goal in DEV@cloud --- I believe the goal is to have DEV@cloud to
be the upgrade from BuildHive, so it needs to have feature parity.)
But it does take a bit of work on our side to support pull request
builds on DEV@cloud instances.
Ultimately, provided that a full DEV@cloud instance has feature parity
with BuildHive, D@C is likely a better place to serve the Jenkins plugin
CI builds, as the community still gets to retain the full control of the
instance, customizing templates, installing plugins, and so on.
So maybe for now we can keep them both, and Nicolas and I work on
enabling the feature parity in jenkins.ci.cloudbees.com?
> The proposal for discussion is to take a snapshot of all our plugin
> jobs on ci.jenkins-ci.org as an archive. Then delete them from
> ci.jenkins-ci.org. Utilize BuildHive as the canonical place for
> Jenkins on Jenkins testing for plugins-only. Continue current usage of
> ci.jenkins-ci.org for core and forked libs.
>
> Comments?
>
> -Jesse
>
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins
R. Tyler Croy
May 22, 2012, 11:59:21 AM5/22/12
to jenkin...@googlegroups.com, Jesse Farinacci
Consider this my plus one for Kohsuke's suggestion :)
- R. Tyler Croy
--------------------------------------
Code: http://github.com/rtyler
Chatter: http://twitter.com/agentdero
rty...@jabber.org
Reply all
Reply to author
Forward
0 new messages