-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins 2.401.1
robot-plugin 3.4.0
-
-
3.5.1
When publishing robot results with :
robot(
logFileName: "**/log.html",
outputFileName: "**/output.xml",
outputPath: 'test_results',
reportFileName: **/report.html,
passThreshold: 100,
unstableThreshold: 100,
onlyCritical: false
)
the plugin correctly display the robot report, the graph and the links towards log.html, output.xml and report.html are correctly created on the build page. The hyperlinks are OK.
Nevertheless, on the build console log displays 2 warnings :
12:59:16 Robot results publisher started... 12:59:16 -Parsing output xml: 12:59:16 Done! 12:59:16 WARNING! Could not find file: **/log.html 12:59:16 WARNING! Could not find file: **/report.html 12:59:16 -Copying log files to build dir: 12:59:16 Done! 12:59:16 -Assigning results to build: 12:59:16 Done! 12:59:16 -Checking thresholds: 12:59:16 Done! 12:59:16 Done publishing Robot results.
saying that neither **/log.html nor **/report.html can be found.
The test_results directory has the followging structure :
test_results
|--<timestamp>
| - <scenario1>
| - Scenario1 test execution related files.
| - <scenario2>
| - Scenario2 test execution related files.
| ... several scenarioX dir ...
|
|- log.html
|- report.html
|- output.xml
I emphasize the fact that though the warnings, the log.html and repot.html links correctly redirect to formatted reports. In other words, the only problem here seems to be the wrong WARNING lines.
[JENKINS-71750] robot-plugin wrongly warn about not found **/log.html
jielpe_fr38 Out of curiousity, why do you have test results still under a dynamic timestamp directory even though they're already inside test_results directory? You probably only need the latest results to be stored anyway, so why add the extra complexity to your design?
Hi,
I already found the root cause for this, which is that wildcards are not treated properly, so when evaluating if the file exists, the plugin check "test_results/**/log.html" literally. I'll try to fix this as soon as possible.
I also changed the bug severity to minor, since this isn't actually affecting the plugin's functionality.