Jenkins keine Tests gefunden - aber in Maven

[Hein_nieH]

Hallo,

ich habe mal wieder ein hoffentlich lösbares Problem.
Ich versuche ein Maven-Projekt vorzubereiten. Als BuildT-ool soll Jenkins zum Einsatz kommen.

Wenn ich in Eclipse das Projekt via Maven baue funktioniert auch alles wie es soll. Insbesondere werden die Tests durchgeführt.

Baue ich das Projekt mit einer fast identischen pom.xml in Jenkins, werden keine Tests durchgeführt.
Ich habe via google versucht auf Beiträge zu stossen, um eine Lösung zu finden, leider ohne Erfolg.

Zum Experimentieren habe ich einen simplen TestFall (diesmal mit richtigen Dateinamen) genommen.

Um das Problem zu verdeutlichen habe ich ein paar Screenshots erstellt.

Es würde mich sehr interessieren wo bei mir der Fehler liegt.
Bei anderen kleinen Übungsprojekten habe ich mehr Erfolg ....

Gruss Hein_nieH

Hier meine pom.xml

[CODE lang="java" title="pom.xml"]<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>DVD_Viewer</groupId>
<artifactId>DVD_Viewer</artifactId>
<version>0.0.1-SNAPSHOT</version>

<name>DVD_Viewer</name>
<description>
Build DVD_Viewer in Jenkins
</description>
<organization>
<name>ich</name>
</organization>

<properties>
<project.build.sourceEncoding>Cp1252</project.build.sourceEncoding>
<project.reporting.outputEncoding>Cp1252</project.reporting.outputEncoding>
<java.version>8</java.version>
</properties>

<!-- Anpassung des Standard-Build-Prozesses -->
<build>
<!-- Festlegen Ressourcen -->
<resources>
<resource>
<!-- Pfad bis zur Ressource setzen -->
<directory>src/main/resources</directory>
<includes></includes>
<excludes>
<exclude>**/*.java</exclude>
</excludes>
</resource>
</resources>

<!-- Anpassung des Build prozesses -->
<plugins>
<!-- Konfiguration des surefire-Plugins anpassen -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M1</version>
<configuration>
<testFailureIgnore>true</testFailureIgnore>
<formats>
<format>xml</format>
<format>html</format>
</formats>
</configuration>
</plugin>

<!-- Konfiguration des maven-compiler-Plugins anpassen -->
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<release>${java.version}</release>
<compilerArgument>-Xlint:all</compilerArgument>
<showWarnings>true</showWarnings>
<showDeprecation>true</showDeprecation>
<debug>true</debug>
<debuglevel>lines,vars,source</debuglevel>
<parameters>true</parameters>
</configuration>
</plugin>

<!-- Konfiguration des maven-jar-Plugins anpassen -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.2.0</version>
<configuration>
<!-- Verändert / Erweitert das default-Manifest -->
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>main.MainClass</mainClass>
</manifest>
</archive>
<!-- Name der jar-Datei aendern -->
<finalName>DVD_Viewer__Git_Test</finalName>
<!-- Ausgabeort für jar-Datei aendern -->
<outputDirectory>C:\Users\${user.name}\Documents\Programmierung_Java\EXPORT</outputDirectory>
</configuration>
</plugin>

<!-- Konfiguration des jacoco-plugins anpassen -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.5</version>
<configuration>
<append>false</append>
</configuration>
<executions>
<execution>
<id>pre-unit-test</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>

<!-- Konfiguration des checkstyle-plugins anpassen -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-checkstyle-plugin</artifactId>
<version>3.1.1</version>
<configuration>
<configLocation>google_checks.xml</configLocation>
<encoding>Cp1252</encoding>
<consoleOutput>true</consoleOutput>
<failsOnError>true</failsOnError>
<linkXRef>false</linkXRef>
</configuration>
<executions>
<execution>
<id>validate</id>
<phase>package</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>

</plugins>
</build>


<!-- Einbindung externer Bibliotheken -->
<dependencies>
<!-- junit jupiter-->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.7.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<version>5.7.0</version>
<scope>test</scope>
</dependency>
<!-- junit 4.12.0 nutzen, selbe version wie eclipse -->
<!-- Notwendig, da Testfälle als Junit 4 konfiguriert sind -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<!-- jfree jfreechart -->
<dependency>
<groupId>org.jfree</groupId>
<artifactId>jfreechart</artifactId>
<version>1.0.19</version>
</dependency>
<!-- jfree jcommon -->
<dependency>
<groupId>org.jfree</groupId>
<artifactId>jcommon</artifactId>
<version>1.0.23</version>
</dependency>
</dependencies>
</project>[/CODE]

 

[LimDul]

Führt maven bei mvn test auf der Konsole die Tests aus?
Sieht im Jenkins Log das das Test Target aufgerufen wird (Vermutlich ja)

Bei sowas immer auch mal auf der Konsole das ausführen lokal - das entspricht in der Regel dem, was Jenkins auch tut.

Ich weiß nicht, ob es mit dem Leeren Package klappt, sollte vermutlich, aber ein echtes Package wäre sinnvoller.

 

[LimDul]

Nachtrag: "Was heißt fast identischer POM?"
Im Jenkins & und lokal nimmt man die gleiche POM. Im Jenkins eine andere POM zu nehmen ist schlicht falsch. Wenn man Abweichungen hat, regelt man das über Properties oder Profile. Aber ein Projekt hat eine POM. Die wird sowohl im Jenkins, als auch lokal genutzt. Alles andere ist grober Unfug und widerspricht dem Kern von Maven.

 

[Hein_nieH]

Hallo LimDul,

im Jenkins Log wird nicht angezeigt, dass ein Test durchgeführt wurde.
Ich vermute, dass es daran liegt, dass die Test-Dateien nicht gefunden werden.
Die Testdatei heisst "DummyTest.java". Das muesste der Namenskonvention für Tests entsprechen.
Ueber den Fehler mit einem ungültigen Namen für Testdateien bin ich schon mal gestolpert.

Gruss Hein_nieH

 

[Hein_nieH]

Hallo,

vielleicht hilft der Build-Path weiter, um die Ursache der bei Jenkins nicht erkannten Tests zu finden, siehe Anhang.
Ich habe zwei typische Maven-Konfigurationen, wie sie bei mir (und bei anderen Usern sicher auch) vorkommen.

Im ersten Konfigurationsbeispiel werden die Tests in Jenkins durchgeführt.

Im zweiten Konfigurationsbeispiel eben nicht. Leider überwiegt die Anzahl meiner Projekte mi dem zweiten Konfigurationsbeispiel.
Wie muesste da die pom.xml geändert werden?

Gruss Hein_nieH

 

[LimDul]

Das zweite ist richtig. Außerdem sind Eclipse Einstellungen ziemlich egal für Maven.

Es fehlen noch die Antworten auf die Frage:
* Was passiert wenn du mit der POM das Projekt auf der Kommandozeilen mit Maven baust?
* Wird wirklich in Eclipse und Jenkins die gleiche POM verwendet?


Edit: Das auf deinem Screenshot vieles nicht in GIT eingecheckt ist, ist dir aber bewusst, doer?

 

[Hein_nieH]

Hallo,

ich habe die pom.xml (welche ich für Jenkins benutze) jetzt auch für Maven (Start aus Eclipse benutzt). Die Tests werden erkannt.
Benutzte ich die exakte gleiche pom.xml für Jenkins werden die Tests nicht erkannt.
Ich versuche es jetzt noch einmal von der Kommandozeile.

Gruss Hein_nieH

 

[Hein_nieH]

Wenn ich Maven von der Kommandozeile starte, werden die Tests auch erkannt.

Gruss Hein_nieH

 

[LimDul]

Erster Schritt: Nur eine POM
Alles andere ist schlich grober Unfug.

Ein Projekt - eine POM. Ansonsten lohnt es sich nicht zu helfen, wenn man Maven derartig versucht zu vergewaltigen

 

[LimDul]

Zweiter Schritt: Wie arbeitet Jenkins - ruft der die Dateien aus GIT ab? Dann würde ich den Test auch mal in commiten & ggf. pushen

 

[Hein_nieH]

Ja die Dateien werden aus GIT abgerufen.
Commiten habe ich gemacht. (Ist in Eclipse auch am Dateisymbol der Testdateien zu sehen).

Gruss Hein_nieH

 

[LimDul]

In dem Screenshot ist davon nix zu sehen - da sind lauter unstaged Changes zu sehen.

 

[LimDul]

Und welche Java-Version verwendest du eigentlich? Dein Eclipse sagt was von Steinzeit (Java 1.5).

 

[Hein_nieH]

Hallo JimDul,

ich verwende Java 11.
Eclipse Version: 2018-09 (4.9.0)

zwar nicht das Allerneuste, sollte aber ausreichen.

Im GIT habe ich nur die Java-Dateien, die pom.xml und die Ressourcen eingecheckt, die im Projekt auch verwendet werden.

Ich kann je zum Test mal alles einchecken.

Gruss Hein_nieH

 

[LimDul]

Momentan zeigt dein Screenshot an, dass es im Ordnet src/test/java Änderungen gibt, die nicht eingecheckt sind.

Den Target Ordner, sowie den den ganzen Eclipse Kram brauchst du nicht einchecken (der sollte standardmäßig in der .gitignorie stehen)

Was sagt den git status?

 

[LimDul]

Ansonsten kannst du ja mal testen - das Repo neu clonen in einen anderen ordner und da mal mvn test ausführen.

 

[Hein_nieH]

ok ich habe in Maven mal ein clean up durchgeführt.
Die nicht genutzten Dateien habe ich in GIT mit ignore versehen.

Mir fehlt momentan eine Idee wie ich weiter komme. Für heute mache ich Schluss.
Morgen würde ich gerne versuchen das Problem zu lösen, leider fehlt mir ein brauchbarer Ansatz ...
Für deine Hilfestellung trotzdem ein großen Dank.

Gruss Hein_nieH

 

[LimDul]

Im Zweifelsfall Projekt zippen und anhängen

 

[mrBrown]

Kleine Dinge die sonst noch auffallen:

• Die Test-Klasse liegt im unnamed-Package, das kann zu Problemen führen und sollte ganz generell vermieden werden. Vor allem kann dein Test so nicht auf deinen restlichen Code zugreifen, der liegt nämlich in einem benannten Package
• Du nutzt als Encoding wieder Cp1252, einfache Regel dafür ist: immer UTF-8
• Du konfigurierst schon wieder Resourcen in der pom, dass solltest du auch lassen (wenn du nicht irgendwas spezielles brauchst, und das brauchst du nicht)
• Du nutzt schon wieder absolute Pfade in der pom, das ist auch absolut der falsche Weg. Immer nur Pfade relativ zum (und innerhalb!) Projektverzeichnis nutzen!

 

[Hein_nieH]

Hallo,

ich habe die Tests in ein reales Package verschoben.
Statt in einem virtuellen Default-Package liegen sie jetzt in einem physisch vorhandenen Package.
Trotzdem werden keine Tests erkannt.

@mrBrown: Die absoluten Pfadangaben in der pom beziehen sich auf die Ressourcen (für das betrachtete Projekt sind es Icon-Dateien).
Diese haben nach meiner Auffassung keinen Einfluss auf die Tests.
Die Tests sind stupide asserTrue(true) Anweisungen (also ohne Codetest), da es hier um die Ursachenermittlung für die nicht erkannten Tests geht.

Gibt es in Maven eine Möglichkeit für Tests einen direkten Pfad einzurichten.
In der Literatur habe ich nichts gefunden.

Gruss Hein_nieH

 

[Hein_nieH]

... zur Vollständigkeit habe ich noch ein Screenshot vom Jenkins-Projektfolder und von der Jenkins-Projektkonfiguration angehängt.
Bei der Projektkonfiguration ist für mich die Fehlermeldung nicht nachvollziehbar.

Gruss Hein_nieH

 

[mrBrown]

zip das Projekt mal und häng es an, rein an zerstückelten Screenshots der Konfiguration kann man wenig sagen.

@mrBrown: Die absoluten Pfadangaben in der pom beziehen sich auf die Ressourcen (für das betrachtete Projekt sind es Icon-Dateien).
Diese haben nach meiner Auffassung keinen Einfluss auf die Tests.

Die absolute Pfadangabe ist in dem Fall der Zielort der gebauten Jar, das kann in diesem Fall gut gehen – ist aber mindestens schlechte Praxis (zB werd ich das Projekt so nicht bauen können, weil die Pfade bei mir einfach nicht existieren).
Und gleiches gilt für die anderen Dinge, die sind nicht direkt ein Problem, machen aber die Nutzung für andere schwieriger und die gesamte Konfiguration unnötig kompliziert und unübersichtlich.

... zur Vollständigkeit habe ich noch ein Screenshot vom Jenkins-Projektfolder und von der Jenkins-Projektkonfiguration angehängt.
Bei der Projektkonfiguration ist für mich die Fehlermeldung nicht nachvollziehbar.

Liegt in target nach dem Build nur der site-Ordner? Dann wird eine Menge mehr als nur die Tests nicht ausgeführt, da fehlt quasi der
gesamte Build.

 

[LimDul]

An der Stelle weiterhin der Rat - räum erst mal auf.
* Eine POM (die Jenkins POM ist falsch.)
* Keine geänderten Datei mehr im Workspace (Entweder Commiten oder in die .gitignore)

Generell mal:
Project in neues Verzeichnis clonen ausführen.

Es ist aktuell total unklar auf welchem Stand jenkins den Code ausführt.
Ansonsten mal den gesamten jenkins log ergänzen.

 

[mrBrown]

@Hein_nieH: Falls irgendwas von dem, was du so machst, in irgendeinem Buch empfohlen wird: Jag es durch 'nen Aktenvernichter und schredder es, übergieße es danach mit Benzin und zünd es an, und verstreu die Asche möglichst weit verstreut auf der gesamten Welt.

 

[LimDul]

@Hein_nieH: Falls irgendwas von dem, was du so machst, in irgendeinem Buch empfohlen wird: Jag es durch 'nen Aktenvernichter und schredder es, übergieße es danach mit Benzin und zünd es an, und verstreu die Asche möglichst weit verstreut auf der gesamten Welt.

Dem muss ich zustimmen. Maven & Jenkins funktioniert eigentlich out of the box ohne das man groß was einstellen muss. Erst wenn man spezielle Dinge brauch, muss man ran. Aber solange man sich an die Standards hält muss man so gut wie nichts konfigurieren.

 

[LimDul]

Noch mal was ausführlicher:


Die Größer Pfeile, die ich unterstrichen habe, sagen "Hier ist der Stand zwischen Workspace und git unterschiedlich".
Konsequenz: Wenn es im Workspace läuft hat das gerade 0 Relevanz, ob es im Jenkins läuft, weil es auf einem unterschiedlichen Stand läuft

Das was ich durchgestrichen habe ist überflüssig und komplett falsch. Es gibt keinen - und in dem Fall meine ich keinen - Grund, zwei POMs zu haben. Ich kann mir überhaupt keinen Fall vorstellen, wo das sinnvoll, geschweige den nötig wäre. Das sagt damit aber auch gerade aus: Wenn es im Workspace läuft hat das gerade 0 Relevanz, ob es im Jenkins läuft, weil es auf einer unterschiedlichen Konfiguration läuft.

Solange diese Probleme nicht behoben sind ist quasi absoluter Unfug an anderen Stellen nach Problemen zu suchen.

Pack den target Ordner in die .gitignore und commite den Rest. Beispiel .gitignore:

/target/

 

[Hein_nieH]

Hallo,

also Literatur lege ich dann mal zur Seite.
Ich versuche jetzt nochmal ein Dummy-Projekt zu bauen bei dem ich die gleiche pom anwende.
Die beiden pom unterscheiden sich nur im exportierten Dateinamen. Das habe ich mir zur Hilfe so überlegt, damit ich weiss, aus welcher Quelle die erzeugte jar-Datei stammt (Sofern es in Jenkins dann auch mal funktioniert.
MrBrown hat recht, die Ursache werden wohl nicht die ausbleibenden Tests sein, da im target-Folder allerhand fehlt.

Ich werde dann berichten.
Gruss Hein_nieH

 

[mrBrown]

Die beiden pom unterscheiden sich nur im exportierten Dateinamen. Das habe ich mir zur Hilfe so überlegt, damit ich weiss, aus welcher Quelle die erzeugte jar-Datei stammt

Was du ja nur brauchst, weil du nen absoluten Pfad dafür angibst die beiden jars sollten ja in völlig verschiedenen Verzeichnissen liegen, dann gibt’s auch keine verwechselungen.

 

[LimDul]

Die Lösung für sowas wäre, einen Default Namen zu vergeben als property und dann die Ausgabedatei auf die property zu setzen. Dann kann man im Jenkins Job die Property von außen mitgeben

 

[Hein_nieH]

Hallo,

ich habe nun das Problem gelöst.
Ursache war nicht die pom.xml sondern der Umstand, dass ich in meinem Git-Repositry fälschlicherweise Dateien aus dem target-Folder eingecheckt habe.
Jetzt funktioniert in Jenkins alles wie es soll.
Na ja wider viel Lehrgeld bezahlt.

Gruss Hein_nieH

 

[mrBrown]

Sicher?

Ein eingecheckter target-Ordner sollte völlig egal sein, Lokal ist der ja auch (meistens) vorhanden und nicht leer – wenn überhaupt hast du dann damit im Jenkins den gleichen Stand wie lokal produziert. Das sollte zumindest nicht der Grund sein, warum es lokal läuft, aber im Jenkins nicht, eher versteckt es andere Fehler, die sich dann ohne eingecheckten Target-Ordner zeigen.