Build Plugin Wrappers

## Two artefacts, two different failure modes The command in the question writes two things a rerun can collide with: the sample log named by `-l`, and the dashboard folder named by `-o`. They behave nothing alike. | Artefact | Already exists, no `-f` | Already exists, with `-f` | |---|---|---| | `-o report` folder, non-empty | `IllegalArgumentException: Cannot write to '<path>' as folder is not empty`; run aborts | Deleted recursively, then recreated | | `-o report` exists as a *file* | `... as it is an existing file`; run aborts | The file is deleted | | `-l results.jtl` | Opened in append mode, no header rewritten | Deleted before the engines start | | `jmeter.log` | Truncated and rewritten every run | Same; `-f` is irrelevant to it | So the loud failure and the silent one live in the same command line, and the loud one is what you actually see on night two. ## Where the folder check happens This matters because it determines what you can conclude from the logs. In JMeter's CLI branch, `extractAndSetReportOutputFolder(parser, deleteResultFile)` runs **before** `startNonGui(...)`. It resolves `-o` to an absolute path, calls `JOrphanUtils.canSafelyWriteToFolder`, and only then sets the property `jmeter.reportgenerator.outputdir` that both exporters read. The consequences worth remembering: - The plan is never parsed, so a JMX error and a dirty workspace look nothing alike in the log. - No JTL is created, so there is no partial results file to inspect. - The check is a plain existence-and-emptiness test. A stray `.gitkeep` or a leftover editor swap file in `report/` is enough to stop the run. - The exporter re-checks the folder later with a *narrower* filter that only looks for `index.html`, `content` and a `sbadmin2-*` directory. That second check is more permissive than the first, so the command-line check is always the one that bites. ## Why the JTL is the more dangerous half A failed build is annoying; a green build reporting the wrong thing is worse. `ResultCollector.getFileWriter` computes, for a CSV log, `trimmed = new File(filename).exists()` and then opens `new FileOutputStream(filename, trimmed)`. The second argument is the append flag. It also writes the CSV header only when `trimmed` is false. Put plainly: 1. Night one creates `results.jtl` with a header and its rows. 2. Night two appends its rows to the same file, with no second header and no separator. 3. Anything that later reads that file — including the dashboard generator — treats the rows of both nights as a single result set. For an XML log the mechanics differ (the closing `</testResults>` terminator is trimmed off the existing file and the new samples are appended in its place, the terminator being rewritten when the file is closed) but the outcome is the same: accumulation, not replacement. ## Fixing it Two defensible fixes, and the choice is about what the job archives: - **Add `-f`.** One flag, and both artefacts are reset. `-f` sets an internal flag that makes the folder check delete the directory tree and recreate it, and that makes the run delete every `ResultCollector` file before the engines start. If a delete fails, you get `IllegalStateException: Could not delete results file ...`, which is again a hard stop rather than a silent carry-over. - **Write into a fresh directory per run.** Point `-l` and `-o` at a path containing the build number or a timestamp. Nothing is ever reused, the collision cannot occur, and the archive step has a naturally unique name to upload. The cost is that the agent's disk grows unless the workspace is cleaned or the paths are inside a directory the job wipes. A nightly job that archives its report usually wants both properties: a clean start *and* a distinguishable output path. The habit worth building is to treat the workspace as dirty by default, because on a reused agent it is. One last trap: `-e` is refused outright without `-l`, with `Option -e requires -l option`. A build step that stops writing the JTL but keeps `-e` will not quietly skip the report — it will complain about usage.