Fix Polarion junitparser merge failure caused by day2ops report XML in test_results

[tusharjadhav3302]

Summary

Move the day2ops procedure report XML from test_results/ (report_dir) to artifacts/
(artifacts_dir) to prevent the Polarion post-run junitparser merge from failing on
non-JUnit XML format.

Problem

The ci-framework Polarion role (roles/polarion/tasks/main.yml) recursively finds all
*.xml files in test_results/ and runs junitparser merge per-directory. The day2ops
report (shiftstack-qa-day2ops-results.xml) sits at the top level of test_results/,
causing the merge command to run junitparser merge test_results/*.xml which includes
the day2ops file. Since the day2ops report uses a custom <shiftstack-day2ops> root
element (not JUnit's <testsuites>), junitparser throws JUnitXmlError: Invalid format.

This causes Zuul to report FAILURE in the Polarion post-run even when all shiftstack
tests pass.

Fix

One-line change: write the day2ops report to artifacts_dir instead of report_dir.
The day2ops report is a custom procedure status XML, not a JUnit test result — it
doesn't belong alongside JUnit XMLs that Polarion processes.

Validation

Manually verified on serval70's shiftstackclient pod (July 15 run):

1. Moved shiftstack-qa-day2ops-results.xml from test_results/ to artifacts/
2. Ran junitparser merge ~/artifacts/test_results/*/*.xml ~/artifacts/test_results/results_merged.xml
3. Merge completed successfully with all 4 test suite XMLs (openstack, lb_amphora, lb_ovn, egressip)

Bug Card

OSPRH-32920

[ekuris-redhat]

Tushar, nice catch on the root cause. The day2ops custom XML breaking junitparser merge in the Polarion post-run makes total sense.

One thing though, main.yml still creates the report file at report_dir (line 39: dest: "{{ report_dir }}/{{day2ops_report_filename }}"), but with your change run_procedure.yml now tries to write to artifacts_dir. Since report_dir resolves to ~/artifacts/test_results and artifacts_dir is ~/artifacts, those are two different paths. So the
community.general.xml module will fail trying to modify a file that doesn't exist at the new location.

You'll need to update all three files together: main.yml needs the directory creation (line 32) and the template dest (line 39) changed to artifacts_dir, run_procedure.yml is already done in this PR, and run_procedure_no_verify.yml has the same report_dir reference that needs the same update.

Other than that the approach is solid, the day2ops report isn't JUnit XML and shouldn't live alongside files that Polarion
processes.

[tusharjadhav3302]

Failing zuul build : https://sf.apps.int.gpc.ocp-hub.prod.psi.redhat.com/zuul/t/components-integration/build/3373f6401663478fabad5524a33d0791

[tusharjadhav3302]

Tushar, nice catch on the root cause. The day2ops custom XML breaking junitparser merge in the Polarion post-run makes total sense.

One thing though, main.yml still creates the report file at report_dir (line 39: dest: "{{ report_dir }}/{{day2ops_report_filename }}"), but with your change run_procedure.yml now tries to write to artifacts_dir. Since report_dir resolves to ~/artifacts/test_results and artifacts_dir is ~/artifacts, those are two different paths. So the community.general.xml module will fail trying to modify a file that doesn't exist at the new location.

You'll need to update all three files together: main.yml needs the directory creation (line 32) and the template dest (line 39) changed to artifacts_dir, run_procedure.yml is already done in this PR, and run_procedure_no_verify.yml has the same report_dir reference that needs the same update.

Other than that the approach is solid, the day2ops report isn't JUnit XML and shouldn't live alongside files that Polarion processes.

Updated all three files. main.yml now creates the directory and writes the template to artifacts_dir, and run_procedure_no_verify.yml has the same report_path update. All day2ops report references are now consistent at artifacts_dir instead of report_dir.

[ekuris-redhat]

lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ekuris-redhat, tusharjadhav3302

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [ekuris-redhat,tusharjadhav3302]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[dlaw4608]

Nice one @tusharjadhav3302 , have you been able to verify your new commit fixing that issue works ? running it again on the already deployed RHOSO deployment?

[tusharjadhav3302]

@dlaw4608 I ran the junitparser merge command through the shifstack-client pod manually and the resullt_merge.xml file was generated as expected. Running the Ansible playbook manually again would reprovision the entire shiftstack cluster and run the tests again . We already had the xml from previous failed runs present so used the same for validation.