4:21 p.m.
Hi Gunnar,
yes it would trigger a build work for any commit happening on any
branch on a registered repository, so also feature branches; In
practice I think it was happening even too often but again the service
is too simple to be configured any differently.
I agree the approach provides good value, that's why I'm looking
forward to see the same Jenkins plugin (the one triggering builds for
pull requests) available on the cloudbees build server; I disabled the
buildhive ones just because of the many false positives which I'm sure
would be solved if we could properly configure all details.
In terms of money, such an account is free to open source projects; in
terms of maintenance it's a matter of configuring the jenkins builds;
can't be too hard as we have such many such machines already, plus
cloudbees manages the platform so basic maintenance should be
hassle-free as well.
I guess we also have the alternative to take the plugin and install it
in our own labs; I didn't say it before as I think that's a bad idea
as it would trigger even more builds, and I don't think we need to
pre-validate each pull request or commit on all supported databases.
Sanne
On 1 June 2012 17:35, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi Sanne,
I was (positively) surprised to get mails for builds of a HV feature
branch, so that's definitely a plus.
Do you know whether that only works for branches in the master
repository (we're having this in HV currently for the first time I
think) or also for branches in (possibly selected) forked repos? If
the latter is the case, I think such builds would provide added value
for HV. Of course I don't how expensive that is (in terms of money and
maintenance efforts).
--Gunnar
2012/6/1 Sanne Grinovero <sanne(a)hibernate.org>:
> Hi All,
> I've had Buildhive configured on some of our projects for the last
> week as an experiment (Hibernate Validator, Search, OGM).
>
> Apologies for all the notifications it made, especially since I didn't
> warn about enabling it.
> Apparently it creates lots of false positives so it has been quite
> noisy on all pull requests and commits.
>
> It was super easy to setup, they definitely made an example to follow
> in terms of service usability and UI: just login with your github
> account, you can setup all projects you are admin of with a single
> mouse click.
>
> Now the bad news:
> it's very limited, for example it wasn't able to build Hibernate ORM
> as you can't choose the gradle version, and it's unable to run the
> Infinispan testsuite as there is a 15 minutes build time limit.
> Hibernate Search builds fails all Byteman related tests, I guess it's
> missing the JDK's tools.jar from the classpath (not available in JRE).
> OGM wasn't that bad, still occasionally it failed with apparently no
> reason.
>
> I've contacted Cloudbees to ask about the gradle version and I was
> suggested to use their standard build platform, for which the same
> pull-request-review plugin will be available soon, and which is much
> more flexible in terms of configuration.
> I think that's a reasonable suggestion and that would give us
> most of the options we need, and we could get it for free as an open
> source project.
>
> It has never been my intention to replace JBoss's internal QA Jenkins
> instances, nor I think that will be possible as only there we have all
> different platforms to test on and all different databases, so I'm
> exploring these options exclusively to get a filter between broken
> pull requests and our reviews: if we can save some time and
> efficiency, I think any additional help is welcome. Also some of the
> tasks run by QA labs would be redundant - like most H2 run tests - and
> we might save resources there for the other tasks by running a
> selection of tests less frequently.
>
> In conclusion: yesterday night I disabled it as I think it had way too
> many false positives.
>
> Shall we proceed in making an Hibernate account to setup some tasks on
> the full-powered Cloudbees version? Again, not with the intention to
> replace the role of "reference CI", but only to get some extra
> processing power - especially the preventive tests on pull requests
> are IMHO very nice.
> I don't think it's a big cost as it's quite easy to configure and
> maintain an additional set of Jenkins instances.
>
> On a side note:
> # I was looking into cloudbees anyway as they have free MongoDB
> instances, so this would help in testing Hibernate OGM.
> # I've tested openshift too for this purpose. Apparently the
> expectation is that you have to commit "to" openshift directly to have
> it trigger a test run: it's currently not able to monitor a different
> git repository so that didn't seem very suited; it might be a good
> place to run tests of demos to run on AS7 though.
> Of course we might "push" the jenkins source code to it an use it as
> was a self-made webapp, but then I think cloudbees would be more
> effective as someone else will manage the platform.
>
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev