After cloning the github repository, updating Maven to 3.0.5, updating the JDK, and executing the build.sh, my build of sonarqube failed after a number of unit test failures, the first of which reads
app_with_severities_when_period_is_set(org.sonar.server.component.ws.ComponentAppActionTest) Time elapsed: 0.007 sec <<< FAILURE!
java.lang.AssertionError: periods[0][2]
Expected: 2014-05-08T00:00:00+0200
got: 2014-05-08T00:00:00-0500
at org.skyscreamer.jsonassert.JSONAssert.assertEquals(JSONAssert.java:222)
at org.skyscreamer.jsonassert.JSONAssert.assertEquals(JSONAssert.java:192)
at org.sonar.server.ws.WsTester$Result.assertJson(WsTester.java:193)
at org.sonar.server.ws.WsTester$Result.assertJson(WsTester.java:183)
at org.sonar.server.component.ws.ComponentAppActionTest.app_with_severities_when_period_is_set(ComponentAppActionTest.java:400)
The build message was
[INFO] SonarQube :: Search ............................... SUCCESS [55.995s]
[INFO] SonarQube :: Server ............................... FAILURE [5:23.832s]
[INFO] SonarQube :: Plugins :: Xoo ....................... SKIPPED
I have obtained this problem on MacOSX, Ubuntu, EL5 and EL6. Is there any way around it?
This is a known issue on test execution with other timezone than Europe/Paris.
You can try building SQ with -Duser.timezone="Europe/Paris"
Related
I am running Jenkins version 1.411 and use Maven for building.
Even though the application builds successfully, Jenkins treats it as an unstable build. I have disabled all tests to isolate the problem.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 45.389s
[INFO] Finished at: Wed May 11 12:16:57 EST 2011
[INFO] [DocLinks] Skip document Adaptiv generated site ... (No such directory: site)
Final Memory: 27M/543M
[INFO] ------------------------------------------------------------------------
channel stopped
Archiving artifacts
Email was triggered for: Unstable
Sending email for trigger: Unstable
An attempt to send an e-mail to empty list of recipients, ignored.
Finished: SUCCESS
It's some time ago that I used hudson/jenkins but you should have a look at the Jenkins Glossary
Unstable build: A build is unstable if it was built successfully and one or more publishers report it unstable. For example if the JUnit publisher is configured and a test fails then the build will be marked unstable.
Publisher: A publisher is part of the build process other than compilation, for example JUnit test runs. A publisher may report stable or unstable result depending on the result of its processing. For example, if a JUnit test fails, then the whole JUnit publisher may report unstable.
So I suppose you have some other build parts (apart from JUnit) that report an unstable result. Have a look at the whole build process log.
If you have unit tests, make sure that they run when executing your build.
In my case, the unit tests are not run and Jenkins tagged the build as Unstable.
When checking the console output, I found that 0 unit tests were running :
[INFO] -------------------------------------------------------
[INFO] T E S T S
[INFO] -------------------------------------------------------
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
The fix for me is will not help resolve this topic but no harm to mention it:
I was Spring boot 2.2 and when I upgraded to v2.5, JUnit 5’s Vintage Engine was removed from spring-boot-starter-test, so I needed to add it to execute tests using JUnit 4.
I have a little bit of strange Problem with Jenkins, Maven and Tycho and it is hard to find out who is the culprit.
All SCM Triggered Builds fail but all manually triggered builds succeed.
Jenkins Version : Jenkins ver. 1.527
Maven Version : 3.05
I have a modularized tycho build:
<modules>
<module>../main.plugin.test</module>
<module>../main.plugin.internationalization.at</module>
<module>../crud.plugin</module>
<module>../rest.plugin</module>
<module>../main.plugin</module>
<module>../main.feature</module>
<module>../product</module>
<module>../target-definition</module>
<module>../rest.plugin.test</module>
</modules>
Jenkins is configured as a simple maven build with modules.
It just executes:
-X clean deploy
When an SCM-Build is triggered some modules are not build.
When I build it manually everything is fine:
This behaviour is consistent. I already tried
switching to a different Maven version (3.05 / 3.04)
deleting the whole workspace prior to building
clean checkout of all sources
running of -X deploy (without clean)
Any amount of manual invocations succeeds. And any amount of scm triggers fails.
Both Maven logs look exactly the same until (working):
[INFO] Reactor Build Order:
[INFO]
[INFO] client-master
[INFO] crud-plugin
[INFO] main-plugin
[INFO] ------------.main.plugin.test
[INFO] ------------.main.plugin.internationalization.at
[INFO] rest-plugin
[INFO] main-plugin
[INFO] ------------.product
[INFO] target-definition
[INFO] ------------.rest.plugin.test
and (failing):
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] main-plugin
[INFO] ------------.plugin.test
[INFO] ------------.main.plugin.internationalization.at
[INFO] rest-plugin
[INFO] main-plugin
[INFO] ------------.product
[INFO] ------------.rest.plugin.test
The final error message therefore is:
Caused by: java.lang.IllegalStateException: ------------..client:------------..crud.plugin:eclipse-plugin:1.0.0-SNAPSHOT does not provide an artifact with classifier 'null'
Customer specific module names are replaced with ------------. in this question.
I have heard repeatedly of vague problems with Tycho builds on Jenkins. The reason for these problems seems to be that some Jenkins plugin triggering these builds hooks into the Maven lifecycle and this somehow collides with what Tycho does in the Maven internals.
For the problem that you are describing, it seems that the Jenkins plugin that you are using is changing the module build order. This may be okay for a normal Maven build (where all dependencies are declared in the POMs), but may fail for a Maven/Tycho build, where dependencies are computed by Tycho during the build.
To avoid this problem, you should trigger the Maven build in a way that is closer to a normal command line build. I found that the Invoke top-level Maven targets build step from the Maven Integration plugin works without problems.
I'm trying to install OpenTripPlanner following the official tutorial.
I've correctly cloned the git repository, then I import the project in Eclipse but it is unable to build all the packages. One of the error is "The import org.geotools cannot be resolved"
So I've tryed with the Maven tutorial but when I run "mvn install integration-test -DskipTests -P interactive" I get:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: org.geotools:library:pom:null
Reason: Cannot find parent: org.geotools:modules for project: org.geotools:library:pom:null for project org.geotools:library:pom:null
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Mon May 20 15:53:31 CEST 2013
[INFO] Final Memory: 44M/473M
[INFO] ------------------------------------------------------------------------
Googling, I've not found anything similar, so, what's the matter?
seems that the geotools.version (and other) properties are not set in the main pom (https://github.com/openplans/OpenTripPlanner/blob/master/pom.xml).
Probably the hudson builder is using variables coming from the settings.xml.
Try defining it manually:
mvn install integration-test -DskipTests -Pinteractive -Dgeotools.version=9.1 -Dspring.version=3.1.1.RELEASE
I am trying to build a multi-module Maven project using Jenkins.
When I build the same project on the command-line using the same environment (variables/settings.xml/user) as Jenkins does, test failures cause the build to fail immediately:
Failed tests:
testSomething(com.package_name.TestSomethingOrTheOther)
Tests run: .., Failures: 1, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.
...
# Build fails immediately
Where-as when building in Jenkins:
Failed tests:
testSomething(com.package_name.TestSomethingOrTheOther)
Tests run: .., Failures: 1, Errors: 0, Skipped: 0
[ERROR] There are test failures.
...
# Build continues to other modules
...
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] parent ................................................ SUCCESS [.....s]
[INFO] module-that-failed .................................... SUCCESS [.....s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
The build states that all modules and parent are SUCCESS-ful, when in reality, these should be failures.
How do I get Jenkins to enforce fail-fast in maven builds as maven does in the command-line?
Thanks in advance.
Jenkins ignores test failures by default, and then marks the build as unstable if they were any.
The parameter that controls that is: testFailureIgnore (see surefire plugin doc)
I've never tried that, but I would attempt to override that setting on the jenkins job configuration:
-Dmaven.test.failure.ignore=false
You can specify MAVEN_OPTS if you click on Advanced button in the Build section.
Is there a Maven plugin that allows you to check if there are newer versions of dependencies available in the repository?
Say, you are using dependency X with version 1.2. Now a new version of X is released with version 1.3. I'd like to know, based on the dependencies used in my project, which dependencies have newer versions available.
The Maven Versions plugin and it's display-dependency-updates mojo are what you're looking for:
mvn versions:display-dependency-updates
Here is what the output looks like:
[INFO] ------------------------------------------------------------------------
[INFO] Building Build Helper Maven Plugin
[INFO] task-segment: [versions:display-dependency-updates]
[INFO] ------------------------------------------------------------------------
[INFO] [versions:display-dependency-updates]
[INFO]
[INFO] The following dependency updates are available:
[INFO] org.apache.maven:maven-artifact ........................ 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-plugin-api ...................... 2.0 -> 2.0.9
[INFO] org.apache.maven:maven-project ....................... 2.0.2 -> 2.0.9
[INFO] org.codehaus.plexus:plexus-utils ....................... 1.1 -> 1.5.6
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 17 seconds
[INFO] Finished at: Fri Aug 15 10:46:03 IST 2008
[INFO] Final Memory: 10M/167M
[INFO] ------------------------------------------------------------------------
If you want to receive email notifications when newer artifacts versions are available on Maven Central you can create an account on artifact-listener and choose which artifact you want to follow.
You can either search manually for artifacts or directly upload your pom.xml.
You will periodically received notifications like this one (available in english and french for now) :
In projects with a large number of dependancies, you sometimes keep your versions in a properties section.
<properties>
<assertj.version>3.15.0</assertj.version>
<aws-sdk.version>1.11.763</aws-sdk.version>
<cxf.version>3.3.6</cxf.version>
In the case where you are only interested in updates to those versions, you can use the following command
mvn versions:display-property-updates
This gives a more condensed view and only returns the versions you need to update in the properties section.
The VersionEye Maven Plugin is doing the same: versioneye_maven_plugin.
VersionEye can notify you about new versions on Maven Repositories, too. It is a language agnostic tool and beside Java it supports 7 other languages. Beside the simple follow/notify feature it can also directly monitor GitHub and BitBucket repositories and notify your about out-dated dependencies in your projects.
There is also a REST JSON API, for tool integrations.
By the way, I'm the dude who started this project. Let me know if you have questions.
The ideal way to do it is to set dependency versions as properties in pom.xml and then running the below command to get the updated versions for your specific/custom dependencies.
<properties>
<java.version>1.8</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
<skip.tests>true</skip.tests>
<spring-cloud-gcp.version>1.2.3.RELEASE</spring-cloud-gcp.version>
<spring-cloud.version>Hoxton.SR6</spring-cloud.version>
<spring-cloud-stream-schema.version>2.2.1.RELEASE</spring-cloud-stream-schema.version>
<confluent.version>5.5.1</confluent.version>
<avro.version>1.10.0</avro.version>
<janino.version>3.1.2</janino.version>
<swagger.version>2.9.2</swagger.version>
<google-cloud-logging-logback.version>0.118.1-alpha</google-cloud-logging-logback.version>
<spring-cloud-stream-binder-kafka.version>3.0.6.RELEASE</spring-cloud-stream-binder-kafka.version>
</properties>
mvn versions:display-property-updates
[INFO] The following version properties are referencing the newest available version:
[INFO] ${avro.version} .............................................. 1.10.0
[INFO] ${spring-cloud-stream-schema.version} ................. 2.2.1.RELEASE
[INFO] ${janino.version} ............................................. 3.1.2
[INFO] The following version property updates are available:
[INFO] ${spring-cloud-gcp.version} .......... 1.2.3.RELEASE -> 1.2.5.RELEASE
[INFO] ${google-cloud-logging-logback.version} 0.118.1-alpha -> 0.118.2-alpha
[INFO] ${spring-cloud-stream-binder-kafka.version} 3.0.6.RELEASE -> 3.0.8.RELEASE
[INFO] ${confluent.version} ................................. 5.5.1 -> 6.0.0
[INFO] ${swagger.version} ................................... 2.9.2 -> 3.0.0
[INFO] ${spring-cloud.version} .................... Hoxton.SR6 -> Hoxton.SR8
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.572 s
[INFO] Finished at: 2020-10-06T09:35:08-07:00
[INFO] ------------------------------------------------------------------------
Another way to achieve this is by executing the command mvn versions:display-dependency-updates but the problem I face with this approach is that it also shows me updates for the nested dependencies which are not too useful for me.
You can use the Versions Maven Plugin[1] to generate reports in your Maven site to get a list of possible updates. With regard to Spring's irregularity, it appears to use the Mercury versioning system[2]. When configuring the Versions plugin, you can add a special rule for Spring stuff:
http://mojo.codehaus.org/versions-maven-plugin/
http://docs.codehaus.org/display/MAVEN/Mercury+Version+Ranges
I might be a bit late to join the party but a more clear way to get more readable html file or a xml file as report which can be taken for further automation using:
mvn versions:dependency-updates-report
This report plugin not just shows more comprehensive details on updates but also has options to update to latest versions. You can find the documentation for it to use various parameters.
You can use Maven Check, a command line tool, which is standalone unlike the Versions Maven Plugin. It also works with Gradle projects.
Output example:
2 build file(s) found, checking for artifact updates
my-gradle-project\build.gradle
[COMPILE ONLY] com.google.guava:guava 31.0-android -> 31.1-android
1 artifact update(s) available
my-maven-project\pom.xml
[DEPENDENCY] org.apache.commons:commons-lang3 3.10 -> 3.12.0
[BUILD PLUGIN] org.apache.maven.plugins:maven-compiler-plugin 3.10.0 -> 3.10.1
2 artifact update(s) available
2/2 build file(s) checked, 3 artifact update(s) available
Disclaimer: I am the author of Maven Check.