You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-dev@db.apache.org by Thomas Fox <Th...@seitenbau.net> on 2011/11/22 04:37:08 UTC
Continuous integration
I have two (independent) opinion polls about our continious integration
setup.
The gump build for torque 4 fails for a long time now. Do we think we need
a gump build ? If yes, does anybody have hints why the build fails ? If
not, how do we remove it ?
Then, I'd like to set up a jenkins build for torque 4. The idea would be to
build all torque components and then run the test project against an
embeddable database (preferably derby). This will tell people in a
reasonable time frame if the last commit broke anything. I'd volunteer to
administer the jenkins build.
As I understand it jenkins is different from gump because gump always takes
the trunks as dependencies and only runs every day, whereas jenkins takes
the real dependency versions and runs after every commit.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Thomas Vandahl <tv...@apache.org>.
On 22.11.11 04:37, Thomas Fox wrote:
> The gump build for torque 4 fails for a long time now. Do we think we need
> a gump build ? If yes, does anybody have hints why the build fails ? If
> not, how do we remove it ?
IMHO Gump creates more problems than it solves. The Gump approach is a
major problem if you are working on an incompatible modifications as we
do now. For example the Turbine build has been failing for a long time
because the torque-maven-plugin has changed.
The project needs to be removed from the Gump configuration (I can do
that). We need to check what projects depend on Torque to make sure we
break no subsequent builds.
> Then, I'd like to set up a jenkins build for torque 4. The idea would be to
> build all torque components and then run the test project against an
> embeddable database (preferably derby). This will tell people in a
> reasonable time frame if the last commit broke anything. I'd volunteer to
> administer the jenkins build.
Yes, please do.
> As I understand it jenkins is different from gump because gump always takes
> the trunks as dependencies and only runs every day, whereas jenkins takes
> the real dependency versions and runs after every commit.
... which is the better solution, because what you really want to know
is whether your *current* build configuration fails, not a imaginary one.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Thomas Fox <Th...@seitenbau.net>.
> > I propose that we let the gump build run until is starts failing (for
gump
> > reasons) and then see if someone fixes ist, if not we drop it. Or does
> > anyboda have any better ideas ?
> >
> > I have configured a jenkins build for the torque 4 trunk, see
> > https://builds.apache.org/view/S-Z/view/Torque/. I'll try to get
checkstyle
> > and findbugs reports published and then plan to create a jenkins build
for
> > the derby-embedded profile of the torque test project.
>
> My counter-proposal would be to terminate the torque-gump-project ASAP,
> now that we have a working Jenkins build. This would resolve my Turbine
> build problems at the same time. I don't see any use in trying to build
> against dependencies that are intentionally incompatible.
>
> I volunteer to remove the configuration. I'd do the same thing for
> Turbine as well.
Fine with me if no-one else objects.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Thomas Vandahl <tv...@apache.org>.
Hi Thomas,
On 05.12.11 03:44, Thomas Fox wrote:
> I propose that we let the gump build run until is starts failing (for gump
> reasons) and then see if someone fixes ist, if not we drop it. Or does
> anyboda have any better ideas ?
>
> I have configured a jenkins build for the torque 4 trunk, see
> https://builds.apache.org/view/S-Z/view/Torque/. I'll try to get checkstyle
> and findbugs reports published and then plan to create a jenkins build for
> the derby-embedded profile of the torque test project.
My counter-proposal would be to terminate the torque-gump-project ASAP,
now that we have a working Jenkins build. This would resolve my Turbine
build problems at the same time. I don't see any use in trying to build
against dependencies that are intentionally incompatible.
I volunteer to remove the configuration. I'd do the same thing for
Turbine as well.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Thomas Fox <Th...@seitenbau.net>.
> > The purpose of gump is to give early warning of when the trunk of
> > project A breaks the trunk of project B. Without gump, you're only find
> > out that project A broke project B way later on, when project A got
> > released and you tried to use the new version.
>
> Yeah, but the problem is if you're project B and cannot do something to
> fix it. Been there, done that, got the scars. I spent way too much time
> to work around Gump issues.
So it seems we do not have consensus about gump
I propose that we let the gump build run until is starts failing (for gump
reasons) and then see if someone fixes ist, if not we drop it. Or does
anyboda have any better ideas ?
I have configured a jenkins build for the torque 4 trunk, see
https://builds.apache.org/view/S-Z/view/Torque/. I'll try to get checkstyle
and findbugs reports published and then plan to create a jenkins build for
the derby-embedded profile of the torque test project.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Thomas Vandahl <tv...@apache.org>.
On 22.11.11 13:05, Graham Leggett wrote:
> The purpose of gump is to give early warning of when the trunk of
> project A breaks the trunk of project B. Without gump, you're only find
> out that project A broke project B way later on, when project A got
> released and you tried to use the new version.
Yeah, but the problem is if you're project B and cannot do something to
fix it. Been there, done that, got the scars. I spent way too much time
to work around Gump issues.
Bye, Thomas.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
Re: Continuous integration
Posted by Graham Leggett <mi...@sharp.fm>.
On 22 Nov 2011, at 5:37 AM, Thomas Fox wrote:
> The gump build for torque 4 fails for a long time now. Do we think
> we need
> a gump build ? If yes, does anybody have hints why the build fails ?
> If
> not, how do we remove it ?
Gump is good :)
According to the error at the bottom of the gump mail, it looks like
the rat plugin is complaining about a licensing issue, and I see some
commits around licensing, so it might fix it:
[INFO] [apache-rat:check {execution: default}]
[INFO] Exclude: velocity.log
[INFO] Exclude: .checkstyle
[INFO] Exclude: derby.log
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Too many unapproved licenses: 1
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1 minute 8 seconds
[INFO] Finished at: Tue Nov 22 03:33:11 UTC 2011
[INFO] Final Memory: 42M/132M
[INFO]
------------------------------------------------------------------------
> Then, I'd like to set up a jenkins build for torque 4. The idea
> would be to
> build all torque components and then run the test project against an
> embeddable database (preferably derby). This will tell people in a
> reasonable time frame if the last commit broke anything. I'd
> volunteer to
> administer the jenkins build.
>
> As I understand it jenkins is different from gump because gump
> always takes
> the trunks as dependencies and only runs every day, whereas jenkins
> takes
> the real dependency versions and runs after every commit.
The purpose of gump is to give early warning of when the trunk of
project A breaks the trunk of project B. Without gump, you're only
find out that project A broke project B way later on, when project A
got released and you tried to use the new version.
That said, a jenkins build will also be useful, as it allows the build
to be tested in more detail and more often.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org