-
Notifications
You must be signed in to change notification settings - Fork 223
Don't log variables (un)set + raw output of module command when cleaning up fake module
#4942
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
Merged
boegel
merged 5 commits into
easybuilders:develop
from
Flamefire:silent-fake-module-cleanup
Sep 8, 2025
Merged
Changes from 4 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
45ce358
Add option to hide output of successful shell commands
Flamefire f0c0a31
Don't log variables (un)set when cleaning up fake module
Flamefire 7f388df
Adapt and extend test
Flamefire 61d9436
Merge branch 'easybuilders:develop' into silent-fake-module-cleanup
Flamefire 361c1ef
rename log subpression options for `run_shell_cmd` and `ModulesTool.r…
boegel File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we use the existing
verbosefor this? something likeThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
verboseis currently solely used for the extended-dry-run and I wasn't sure of the impact.My new idea would be:
if verbose or debug-option: Print settingSet
verbose=Falsefor all module command uses and the fake module unset.Also only log output of module commands (lmod calls) when debug-option is set
The changes by the module commands are usually not interesting and just make the log harder to read. So suppressing them by default but with an option to show them sounds like the most sensible approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually at least the reports from boegelbot runs include the debug flag so that wouldn't make those reports more readable :-/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given the limited length of the failed report, we can very well disable
debugin the bot. Most of the time debug logs are useless when a build fails anyhow, in that case you just need the output of the failing command/test/sanity check. We can discuss about this in the next call.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So shall we go forward with my proposal above or wait for the call too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I strongly prefer keeping
debugenabled in the bot, since it does result in a better log (though less easy to parse).I think selectively making
setvarlog less as is being done here makes sense.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd want to make a more general decision here. Basically what we usually don't want is output from a)
module commands(proposed, not yet implemented) b) variables set by loading modules c) variables changed by unloading modules, especially the fake/real-module in the sanity checkThat information might still be useful in limited contexts, e.g. during debugging strange failures, so logging it with
--debugsounds reasonable as otherwise there won't be any way to show those.But if those information is shown with
--debugand the test reports use--debugwe haven't gained anything for that common use case.How do we address this?
We could introduce debug levels, similar to how
-vvis more verbose than-vin other programs.Or we could use
--debug --traceas "log more debug info"There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have an extra level of logging (
--devel), we could only log those details when devel log level is used?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, we're sort of discussing this in the wrong place.
I'm about to merge this PR, and discussing stuff in closed PRs is something we should definitely avoid...
@Flamefire Can you open an issue to follow-up on this, beyond the changes made in this PR?