-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What do we want for the reproducer #31
Comments
@rhornung67 @davidbeckingsale @mcfadden8 I am leaning toward option 3, printing something like:
Which prepares your shell for the 3 options, and all you have to do is, for example:
|
Since the reproducer is in the Shared CI, and we are trying to strip Spack out of the Shared CI, I just changed my mind: My new preferred option is simply to default to USE_DEV_SHM=false in the build and test script. This keeps the reproducer simple. |
Introduction
RADIUSS Shared CI prints an almost(*) exact reproducer in the logs of each job.
The requirements were:
(*) The reproducer is almost exact, as it cannot capture the variables that where set in extra jobs. E.g., running address sanitizer may require to set some variables, those would not be know by the reproducer which is defined in RADIUSS Shared CI.
The current reproducer logic has defaults inherent to it’s initial specifications: It mimics the CI job and it’s optimizations, meaning it runs with the service account, in an allocation and using the shared memory (/dev/shm) to speed up the run.
Proposition
I suggest we improve this reproducer so that it becomes more convenient to use. In particular, I would like it to be easily usable by a developer to debug a CI job.
I would like to support 2 use cases
Options
The text was updated successfully, but these errors were encountered: