Fix Allure artifacts reported as null links

[DavertMik]

Allure artifacts uploaded to S3 successfully but arrived at Testomat.io as "artifacts":[null,null,null], so nothing rendered in the UI — neither in the artifacts block nor in steps. Reported against 2.10.0 and 2.13.0; present since #852.

Root cause

uploader.uploadFileByPath() resolves to the S3 link as a plain string (src/uploader.js:271), but AllureReader.uploadArtifacts() treated it as an object:

test.artifacts = artifacts.filter(a => a && a.link).map(a => a.link);

Reading .link off a string doesn't yield undefined — it hits String.prototype.link, the legacy Annex B HTML method. That function is truthy, so:

• the filter keeps every element, and the count stays right
• 🗄️ Uploaded 3 artifacts prints, so the log looks healthy
• the map yields three functions
• JSON.stringify serializes functions inside an array as null

kept: 3   typeof mapped[0]: function   JSON: {"artifacts":[null,null,null]}

This explains every symptom, including why no configuration helped: the upload genuinely succeeded and the file really was in the bucket — only the link was destroyed on the way into the payload. No combination of Share credentials, env credentials, or TESTOMATIO_PRIVATE_ARTIFACTS could have worked around it.

Step attachments were dropped entirely

processAllureResult read only result.attachments, and convertSteps ignored step.attachments. Attachments made inside Allure.step were never uploaded or referenced.

They are now collected per step, uploaded under <runId>/<rid>/steps/, and written back to step.artifacts as links — matching the convention in client.js, where step artifacts render inline in the step tree and stay out of the test-level list.

Behavior change worth a look: on the repo fixtures, sample_allure/backend goes from 0 → 6 artifacts and sample_allure/ios from 1 → 9. Teams that attach request/response dumps to every step will see S3 volume per run grow accordingly. TESTOMATIO_ARTIFACT_MAX_SIZE_MB remains the throttle.

Also noting: when S3 credentials are absent, step artifacts fall to the deferred upload-artifacts path, which re-attaches by test rid — so on that path they land at test level and lose step placement.

Same bug class in XmlReader

src/xmlReader.js:536 had no filter at all, so skipped and failed uploads leaked undefined → null into JUnit payloads. Fixed, and the log now reports the real count rather than the attempted count.

Test plan

• New tests/unit/allure_artifacts_test.js asserts on the JSON round-trip. A length or truthiness check would have passed against the broken code; against the original it fails with expected [ null, null, null ] — the exact reported payload.
• npm test: 550 passing, 0 failing (baseline 545/0).
• npm run build and npm run lint clean; verified the fix is present in lib/ and that lib/allureReader.js loads under CommonJS.
• End-to-end over sample_allure/ios and sample_allure/backend with a stubbed uploader: real URLs at both test and step level, zero nulls.
• The 2 failing tests in tests/adapter/allure-integration.test.js are pre-existing (sample_allure/android/allure-results doesn't exist — only allure-report) and untouched here.

🤖 Generated with Claude Code