Grinder Change default KEEP_REPORTDIR from true to false to reduce disk overhead
- Dominant language
- HTML
- Stars
- 155
- Forks
- 346
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 36
Description
## Summary
The Grinder Jenkins job config currently has `KEEP_REPORTDIR` explicitly set to `true`
as the saved default parameter. The pipeline code (`JenkinsfileBase`) defaults to `false`,
but the Grinder job config overrides it, meaning any Grinder run inherits `true` unless
the user explicitly changes it.
## Background
This was identified during a disk space incident (runtimes/infrastructure#[11982](https://github.ibm.com/runtimes/infrastructure/issues/11982)) where
a Grinder run with `TKG_ITERATIONS`: 100 iterations and `KEEP_REPORTDIR`=true exhausted disk on a Windows agent.
Confirmed with @smlambert that the `true` default in the Grinder job config was unintentional/we need to revisit to understand why that change was made.
## Proposed Change
Change the Grinder job config default for `KEEP_REPORTDIR` back to `false`.
`KEEP_REPORTDIR=true` is useful for debugging (inspecting work/report dirs after a run)
but should not be the default for general Grinder use, especially with high iteration counts.
## Related
- https://github.ibm.com/runtimes/infrastructure/issues/11982
- @marcus-wornast's suggestion to cap max iterations under disk-constrained conditions
(~40G max overhead) is a separate but related follow-up
Contributor guide
Research direction
Start by locating the Grinder job configuration and the KEEP_REPORTDIR handling in JenkinsfileBase. Confirm that the saved Grinder default currently differs from the pipeline default, change the job default to false, and verify that new Grinder runs no longer inherit true unless selected explicitly.
Written by the indexing model from the issue text.
Assessment
- Domain
- ci-cd, testing
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100