I don't have the privilege to view/edit the Jenkins job configuration,
so, I can not see the command from there.
Somehow, I am not able to figure out the command from the console, can
you help me here by telling the command ( for running the
Mahout-Examples-Cluster-Reuters build )?
Can you also help by clarifying the protocols on the builds? i.e. which
builds to test before committing. How much time is allowed to fix
failing builds ( how much time for which build ), or is there something
like this?
Is it needed to run/build the Mahout-Examples-Cluster-Reuters ( along
with Mahout Quality i.e. mvn clean install on trunk ) before
committing, and if yes, is it a common practice?
Is this info about the builds documented somewhere? If the information
about the builds is not documented anywhere, then I would will like to
add it to the mahout wiki/site/somewhere i.e. which all builds do we
have, and which one is needed for what purpose and other rules for them.
If it is already documented, can you please share that link?
I don't think Jenkins is behaving differently than my local box.
Paritosh
On 20-03-2012 02:51, Isabel Drost wrote:
On 17.03.2012 Paritosh Ranjan wrote:
Is there any way to test this build before commit? The trunk is building
successfully and till now, that's all I check before commit. How do I
test this build before commit?
As far as I know "all" you have to do is to use the same commands that Jenkins
uses to trigger the build*. Don't know at the top of my head which options it
uses, you should be able to find out by going to Jenkins, selecting our build
and clicking configure (you need to be logged into Jenkins for that) or
selecting the last build that failed and looking at its console output.
From just briefly scanning the output it looks like after successfully
triggering the maven build it fails when executing the cluster_reuters.sh
script.
Isabel
* Obvious other culprits for Jenkins behaving differently than you local box are
different network settings, different maven versions, different settings.xml,
different java version, screwed up local maven repositories on either side and
such - however I don't think neither of those is particularly likely in this
case.
