kola-junit: switch python-junit-xml to junitparser

[c4rt0]

python-junit-xml was orphaned in Fedora 44, blocking the COSA rebase. Replacing it here with junitparser, which is actively maintained.

Closes #4573

[gemini-code-assist]

Code Review

This pull request replaces the deprecated junit_xml library with junitparser across dependencies and the kola-junit script. The review feedback identifies a critical bug where assigning a list to tc.result will raise an AttributeError, and suggests a more portable way to handle standard output writing instead of using /dev/stdout directly.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Writing to '/dev/stdout' via xml.write() can be problematic in certain restricted environments (such as containerized builds or chroots) where /dev/stdout might not be available or writable. A more robust and portable approach is to write the serialized XML bytes directly to sys.stdout.buffer using xml.tostring().

Suggested change

	if args.output == '-':
	TestSuite.to_file(sys.stdout, [ts])
	xml.write('/dev/stdout')
	else:
	with open(args.outputxml, "w", encoding='utf-8') as f:
	TestSuite.to_file(f, [ts])
	xml.write(args.output)
	if args.output == '-':
	sys.stdout.buffer.write(xml.tostring())
	else:
	xml.write(args.output)

[jbtrystram]

LGTM at a glance. Can you do a test run with the pipeline ? You can use the image konflux built :)

[c4rt0]

LGTM at a glance. Can you do a test run with the pipeline ? You can use the image konflux built :)

Thanks @jbtrystram, I will give it a go today.

[c4rt0]

@jbtrystram - I figured it out.

I got the PR's commit SHA and pulled the Konflux built image from the quay, then ran coa build and kola run based on this so that scripts and dependencies came entirely from that image:

Just for future reference in case I need to do this again:

✘ adamsky@lenovo  ~/Work/cosa  gh pr view 4577 --repo coreos/coreos-assembler \
  --json commits --jq '.commits[-1].oid'

-> Produced:
d92898...

 ✘ adamsky@lenovo  ~/Work/cosa  gh pr view 4577 --repo coreos/coreos-assembler \
  --json statusCheckRollup \
  --jq '.statusCheckRollup[] | "\(.name) | \(.status) | \(.conclusion)"' \
  | grep -i konflux

-> produced:
Konflux kflux-prd-rh03 / coreos-assembler-main-on-pull-request | COMPLETED | SUCCESS

adamsky@lenovo  ~/Work/cosa  cd ~/Work/cosa
cosa init --force https://github.com/coreos/fedora-coreos-config
cosa build
COREOS_ASSEMBLER_ADD_CERTS=1
COREOS_ASSEMBLER_CONTAINER=quay.io/redhat-user-workloads/coreos-tenant/coreos-assembler-main:on-pr-d92898...


 adamsky@lenovo  ~/Work/cosa  COREOS_ASSEMBLER_GIT= cosa kola run podman.base
...

 ✘ adamsky@lenovo  ~/Work/cosa  podman run --rm --entrypoint="" \                                                                                
  quay.io/redhat-user-workloads/coreos-tenant/coreos-assembler-main:on-pr-d92898... \
>   rpm -q python3-junitparser

python3-junitparser-4.0.2-1.fc43.noarch

🎉

 adamsky@lenovo  ~/Work/cosa  podman run --rm --entrypoint="" --security-opt=label=disable \
  -v ~/Work/cosa/tmp/kola:/data:ro \
quay.io/redhat-user-workloads/coreos-tenant/coreos-assembler-main:on-pr-d92898... \ 
/usr/lib/coreos-assembler/kola-junit \
    --classname kola --koladir /data --output -
<?xml version='1.0' encoding='utf-8'?>
<testsuites><testsuite name="kola" tests="1" errors="0" failures="1" skipped="0" time="3.012"><testcase name="podman.base" classname="kola.tests" time="3.012158318"><system-out /><system-err /><failure message="Test failed">        harness.go:1928: Cluster failed starting machines: exit status 1
</failure></testcase></testsuite></testsuites>%    

The xml above feels like a relief.

Can you do a test run with the pipeline ?

That's now next.

[c4rt0]

Pipeline test which I triggered on stg (build #3) didn't work as expected. Jenkins couldn't parse the XML:

org.dom4j.DocumentException: An invalid XML character (Unicode: 0x1b) was found in the element content of the document.

0x1b is the escape character used in ANSI escape codes. There is probably some work required around the currently existing strip_ansi() in kola-junit as it does not catch all of the cases. junitparser uses lxml which turns out to be strictier than the old library and rejects these characters. I'm investigating on how to best handle this...