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
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.
Either way, +1 for archiving and deleting from
ci.jenkins-ci.org.
>
> Comments?
>
> -Jesse
>
--
Kohsuke Kawaguchi | CloudBees, Inc. |
http://cloudbees.com/
Try Nectar, our professional version of Jenkins