Allow rendering of simple reports (without graphs) on headless machines

[u3r]

Feature Description

Since the new report plugin (I think somewhere around 1.8) can render graphs and plantuml it depends on a running graphics backend. In other words it fails hard on a jenkins without X11 configured. I am not reporting this as a bug, since I a) don't have a portable testcase for you :( and b) am not too sure whether the rest of the world doesn't mind this restriction.

I, as a developer would like to generate simple reports of rule-checks (without rendered graphs) on a jenkins instance that runs without a display (x11) configured. Both lazy initialization (only if there are graphs to be rendered) or a config-option (supported by the maven-plugin) to disable graph rendering are ok.

How to Test

When I try to do this today, I get an exception (on headless jenkins) Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable. (full exception attached x11_needed.txt )

I have traced this problem to the fact that https://github.com/jQAssistant/jqa-asciidoc-report-plugin/blob/master/src/main/java/com/buschmais/jqassistant/plugin/asciidocreport/plantuml/AbstractPlantUMLReportPlugin.java defines a constant with the value of FileFormat.SVG.name() which in turn initializes a buffered image triggering the problem.

To test this feature... Use a jenkins build without X11 configured and render any report result without graphics to be rendered.

Definition of Done for the Implementers

Remove this hint: these checkboxes can be checked like this: [x]

• [ ] We got a final feedback from the reporting user (if applicable)
• [ ] Unittests have been written (if applicable)
• [ ] Integration tests have been written (if applicable)
• [ ] Test coverage is the same or even better then before (if applicable)
• [ ] Documentation has been written (if applicable)
• [ ] Added a note on the new feature to the release notes (if applicable)

[u3r]

I just noticed that even just using the jqa-maven plugin in a build while not calling the report goal is enough to fail the build. Should I raise this as bug in the plugin repository?

[DirkMahler]

The issue is at the right place here.

What's puzzling me is that we're executing jQA within several Jenkins/Bamboo/etc. builds in headless environments and we did not face this yet... Which Java version are you using?

[u3r]

07:45:00  + mvn -version
07:45:00  Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
07:45:00  Maven home: /var/jenkins_home/maven/apache-maven-3.8.x
07:45:00  Java version: 11.0.13, vendor: Eclipse Adoptium, runtime: /var/jenkins_home/java/jdk-11.0.13+8
07:45:00  Default locale: en_US, platform encoding: UTF-8

We're not configuring Xvfb around the build. Neither are we passing java.awt.headless=true to the maven process.

Edit: when passing java.awt.headless=true the build works but I still feel it would be best if that wasn't necessary.

[DirkMahler]

I have an idea on how it could be fixed but sadly I cannot reproduce the issue (and thus not verify if the solution actually works).

Question: Would you be able to run a SNAPSHOT version of the Maven plugin to verify, i.e. would you be able to temporarily add Sonatype OSS Snapshots (https://oss.sonatype.org/content/repositories/snapshots/) to your settings.xml? Otherwise you'd need to wait for an RC or the next official release to check.

[u3r]

Hi @DirkMahler, normally our Jenkins is configured to prevent exactly that but I'm asking around whether we can do a test.

[u3r]

Hi @DirkMahler,

sadly getting snapshot repositories accepted here at work is going to be a hassle. Could your idea be tested by replacing the FileFormat constant with some mock that just throws an exception in initialization?

[DirkMahler]

Indeed, will try to remove the default enum value. Will be solved in 1.12.0.

[DirkMahler]

Fixed.