-
Bug
-
Resolution: Fixed
-
Critical
-
None
-
Platform: All, OS: Linux
-
Powered by SuggestiMate
Hudson does not send failure e-mails when maven fails to validate a pom (easy to
reproduce by using a random text file as a pom).
This might be a maven embedder issue, but the shell command does return 1 (at
least for maven 2.0.8).
(this is on unix, no idea about whether this works on windows)
- is duplicated by
-
JENKINS-2595 Mail is not send
-
- Closed
-
-
JENKINS-1609 when a wrong mvn target is given, build failures are not notified through email
-
- Closed
-
-
JENKINS-1653 E-mail notification fails if check out fails
-
- Closed
-
-
JENKINS-1818 pom parse error doesn't trigger email notification
-
- Closed
-
-
JENKINS-3955 module-pom failures do not trigger mails (was: m2extra-steps stops build failure mails)
-
- Closed
-
[JENKINS-1066] No e-mail when maven fails before a build starts
Updating the title to reflect the issue better. Bumping up the priority given
the number of dupliates filed.
This issue bit me, too.
http://www.nabble.com/Hudson-did-not-send-email-on-broken-build-td21696798.html
Kawaguchi-san,
Unfortunately I haven't had time to fix this issue, so let me reassign this to you.
Thanks,
Kenji
This appears to be fixed as of 1.290. I wrote several unit tests but this no
longer reproduces.
This does not appear to be fixed. I see this problem on Ubuntu using the
built-in Winstone container and Hudson ver. 1.292, as well as another version
from a few weeks ago from which I upgraded by simply replacing the war file and
restarting Hudson.
I could reproduce this on my debian box also, and I think it is valid on all
platforms. I verified that free-style works with a bad pom.xml.
Steps to reproduce:
1. Create a maven job
2. Build once to get a workspace
3. Create a fake pom.xml in the workspace
4. Build again (with the default pom.xml)
Actual outcome:
Exception stack in output, no email was to sent
Expected outcome:
Exception stack in output and all post build notifications should be executed
I noticed that it also happens if maven cant find any pom.xml either, and then
no stack trace was provided. This works fine in free style jobs.
Build with no pom.xml with email notification:
------------------------------------------------------
Started by user redsolo
Building remotely on redsolo
Parsing POMs
ERROR: No such file /var/hudson/workspace/test 1066/pom.xml
Perhaps you need to specify the correct POM file path in the project
configuration?
Finished: FAILURE
------------------------------------------------------
Build with invalid pom.xml with email notification:
------------------------------------------------------
Started by user redsolo
Building remotely on redsolo
Parsing POMs
ERROR: Failed to parse POMs
hudson.util.IOException2: remote file operation failed
at hudson.FilePath.act(FilePath.java:596)
at
hudson.maven.MavenModuleSetBuild$RunnerImpl.parsePoms(MavenModuleSetBuild.java:4
26)
at
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:315)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:272)
at hudson.model.Run.run(Run.java:923)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:234)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:119)
Caused by: hudson.remoting.ProxyException:
hudson.maven.MavenModuleSetBuild$MavenExecutionException:
hudson.maven.MavenEmbedder$1: Not a v4.0.0 POM. for project unknown at
/var/hudson/workspace/test 1066/pom.xml
at
hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:750)
at
hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:676)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1583)
at hudson.remoting.UserRequest.perform(UserRequest.java:97)
at hudson.remoting.UserRequest.perform(UserRequest.java:46)
at hudson.remoting.Request$2.run(Request.java:236)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:8
86)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: hudson.remoting.ProxyException: hudson.maven.MavenEmbedder$1: Not a
v4.0.0 POM. for project unknown at /var/hudson/workspace/test 1066/pom.xml
at hudson.maven.MavenEmbedder.readProject(MavenEmbedder.java:325)
at
hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:730)
... 11 more
Caused by: hudson.remoting.ProxyException:
org.apache.maven.project.InvalidProjectModelException: Not a v4.0.0 POM. for
project unknown at /var/hudson/workspace/test 1066/pom.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjec
tBuilder.java:1581)
at
org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjec
tBuilder.java:1553)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(
DefaultMavenProjectBuilder.java:504)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBui
lder.java:215)
at hudson.maven.MavenEmbedder.readProject(MavenEmbedder.java:323)
... 12 more
Finished: FAILURE
------------------------------------------------------
Adding myself as CC.
As a workaround we are using a free-style software project instead of the
maven2 project, so we are loosing all the benefits from the maven2 project. Is
there another workaround for this bug?
Taking issue. Should be fixed in 1.324 - I added a call to MailSender
(conditional on MavenMailer being configured for the project) in the cleanUp
method at the top-level MavenModuleSetBuild.RunnerImpl, so that we actually get
an email for the entire Maven project, not just one per module. That said,
email-ext does the trick on this too.
Code changed in hudson
User: : abayer
Path:
trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=21509
Log:
[FIXED JENKINS-1066] Added call to MailSender in RunnerImpl.cleanUp so that mail gets sent for top-level Maven project as well as individual modules. Also, William the Conqueror won the Battle of Hastings in 1066. Just thought I'd mention that.
Can this fix please be optional?
we use subversion and now for some reason when a poll is done and even when nothing in subversion has changed a email is trigger if the subversion server cannot be reached.
from time to time due to network issues. planned and unplanned maintance on the network and or dns server, subversion will not be reachable (mainly on weekends)
if the svn server cannot be reached we do not want a email triggered.
over the weekend this caused over 5000 emails over 1.5 days sent to developers who now thing hudson is a buggy system.
error:
Started by an SCM change
Building remotely on RHEL5.2_x86_64VM1
Updating http://subversion/dev/project/trunk
ERROR: Failed to update http://subversion/dev/project/trunk
org.tmatesoft.svn.core.SVNException: svn: unknown host
svn: OPTIONS request failed on '/dev/project/trunk'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:103)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:87)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:616)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342)
at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:699)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:660)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2018)
at hudson.remoting.UserRequest.perform(UserRequest.java:69)
at hudson.remoting.UserRequest.perform(UserRequest.java:23)
at hudson.remoting.Request$2.run(Request.java:213)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.net.UnknownHostException: svnglobal
at java.net.InetAddress.getAllByName0(InetAddress.java:1157)
at java.net.InetAddress.getAllByName(InetAddress.java:1083)
at java.net.InetAddress.getAllByName(InetAddress.java:1019)
at java.net.InetAddress.getByName(InetAddress.java:969)
at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createAddres(SVNSocketFactory.java:132)
at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:54)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:183)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:323)
... 22 more
rajpra what you seem to be referring to is more related to issue like JENKINS-10173 or JENKINS-763
PS: I think subversion checkout error should be handled as build errors!
This issue came back again in the dev list:
http://www.nabble.com/hudson-plugins-pom.xml-parsing-problem-tt14645157.html