GeezerVison

[P2] Do not disable valid per-instance Playwright source configuration

Playwright also accepts source roots through Playwright.create(new Playwright.CreateOptions().setEnv(Map.of("PLAYWRIGHT_JAVA_SRC", sourceRoot))); the variable does not have to exist in the JVM's process environment. With this supported configuration and allure.playwright.trace.sources=true, this check returns false, so startTracing() sets sources=false and skips trimming.

I reproduced the mismatch against Playwright 1.62.0: its real StackTraceCollector.createFromEnv() accepts the instance configuration, while the Allure helper passes StartOptions.sources=false. The new real-trace test uses this same setEnv() mechanism, but starts tracing directly rather than through AllurePlaywright.startTracing(), so it does not cover this failure.

Please let the opt-in property enable source embedding without requiring System.getenv() to contain the source roots, and cover the per-instance configuration through the public helper.

Fixed in ffc9e1b. I dropped the System.getenv check, so allure.playwright.trace.sources=true now passes setSources(true) by itself. Playwright reads PLAYWRIGHT_JAVA_SRC from CreateOptions.setEnv() first and falls back to the process environment. If it's set in neither, no stacks are recorded, the trace has no trace.stacks, and the trimmer leaves it untouched. AllurePlaywrightEmbedSourcesTest now covers this through AllurePlaywright.startTracing() with setEnv(). It checks that sources are embedded and that frame 0 resolves to the test class.

[P2] Stream unchanged entries instead of buffering every decompressed resource

This reads every ZIP entry fully into heap, including screenshots and captured network response bodies, even though only trace.stacks needs transformation. ByteArrayOutputStream grows an unbounded backing array and toByteArray() then allocates another full copy. The resources/ handling below does not skip this allocation.

I reproduced an uncaught OutOfMemoryError in TraceStackSourceTrimmer.readAll() using a 49,237-byte ZIP containing a 48 MiB resource and a valid trace.stacks entry, with a 64 MiB child-JVM heap. Neither this class nor DefaultTraceSession.stop() catches that error, so trace diagnostics can disrupt test execution instead of failing open and attaching the original archive.

Please copy unchanged entries with bounded memory, buffering only the stack JSON. Preserving their original compressed payloads would also avoid unnecessary decompression.

Fixed in ffc9e1b. The trimmer now edits the archive through the JDK zip filesystem (FileSystems.newFileSystem(trace)). Only trace.stacks is read and replaced. The other entries are copied with their original compressed payloads, so screenshots and network bodies are no longer decompressed into memory. It still fails open: the zip filesystem writes the new archive to a temp file and swaps it in only on success, and any IOException or RuntimeException leaves the original trace as it was.

[P2] Preserve compression for text resources

Every resources/ entry reaches this branch, but that directory contains compressible HTML, JavaScript, JSON response bodies, and embedded Java sources, not only already-compressed screenshots. Writing all of them as STORED can substantially increase the trace attachment size.

Running this trimmer on the PR's own trace-before.zip increased the archive from 17,968 to 28,554 bytes (about 59%). Its HTML resource alone expanded from 2,301 compressed bytes to 6,639 stored bytes. Larger or text-heavy traces will incur unnecessary attachment storage, transfer, and loading costs.

Please preserve unchanged entries' compressed payloads, or at least retain compression for compressible resources rather than treating the entire resources/ directory as incompressible binary data.

Fixed by the same change. Unchanged entries keep their original compression method and compressed bytes, and the resources/ → STORED special case is gone. shouldPreserveCompressionOfUnchangedEntries checks that a compressed HTML resource keeps its exact compressed size and that a STORED binary entry stays STORED.