camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Earls <kea...@redhat.com>
Subject Re: Automated testing of pull requests?
Date Mon, 21 Dec 2015 13:23:26 GMT
Hi Claus,

I have been looking at doing something similar on the Fuse Jenkins
(see camel-2.15.0.redhat-6-3-x-checkin-incremental and ENTESB-4481) for our
next release as the newer versions of Jenkins support incremental builds.
I haven't spent a lot of time on it yet but so far it looks like most Camel
build take 1-1.5 hours instead of the usual 4 or so.

I'm not sure yet if we can turn this into a PR job but if I get it
straightened out the same thing could be done upstream.

Cheers,

Kevin

On Mon, Dec 21, 2015 at 7:47 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> Hi
>
> There is about 16.000+ unit tests in the Camel source code. And it
> takes like 4-6 hours to run depending on computer power. And a of the
> test may fail due "port number in use" issues etc.
>
> However if the PR is only changing files in a component (which most of
> them really are) then we could run the tests only for that component -
> which the person doing the PR should really also have done. Then the
> testing is feasible to run. I wonder if that would be possible, eg if
> it can somehow detect which camel component the PR is only affected,
> and only do the test/build of that, so if you chance camel-quartz2,
> then it does a
>
> cd components
> cd camel-quartz2
> mvn clean install
>
> or something to only unit test that.
>
> Not sure if it would need to build SNAPSHOT dependencies of the entire
> project first to have them up to date, eg so camel-core etc is build
> prior? As we have so many components that takes like 30 min to do,
>
> If so its 2 steps
>
> mvn install -Pfastinstall
> cd components
>
> cd camel-quartz2
> mvn clean install
>
>
>
> And we can also run the checkstyle rule before hand also to catch code
> formatting issues.
>
>
> On Sun, Dec 20, 2015 at 11:38 AM, Pascal Schumacher
> <pascalschumacher@gmx.net> wrote:
> > Hi everybody,
> >
> > what about setting up automated testing of pull request?
> >
> > The build server automatically build the pull request and updates it with
> > the results: e.g. https://github.com/apache/commons-lang/pull/119
> > https://github.com/apache/groovy/pull/214
> >
> > This gives the person submitting the pull request fast feedback and
> allows
> > him to fix any errors.
> >
> > Also the person merging the pull request can see if the merge will cause
> any
> > problems.
> >
> > Setting this up is easy.
> >
> > You can either use builds.apache.org, where you set up job like this
> one:
> > https://builds.apache.org/view/Groovy/job/Groovy%20Github%20PRs/ and
> create
> > a infra ticket to activate the github integration.
> >
> > Or you can use travis-ci, if you add a .travis.yml file to the repo and
> > create an infra ticket to enable travis-ci integration.
> >
> > What do you thinks?
> >
> > Cheers,
> > Pascal
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message