Stop git.latest logging a spurious rev-parse error on first clone#69697
Open
ggiesen wants to merge 3 commits into
Open
Stop git.latest logging a spurious rev-parse error on first clone#69697ggiesen wants to merge 3 commits into
ggiesen wants to merge 3 commits into
Conversation
is_worktree() probes cwd with 'git rev-parse --show-toplevel' and expects that command to fail (retcode 128) when cwd is not a git repository, which it already handles by catching CommandExecutionError and returning False. However _get_toplevel() ran the probe without ignore_retcode, so cmd.run_all logged the expected failure at ERROR level, producing noise such as: [ERROR ] Command 'git rev-parse --show-toplevel' failed with return code: 128 Add an ignore_retcode parameter to _get_toplevel (default False, preserving behaviour for other callers) and pass ignore_retcode=True from is_worktree's probe so the expected failure no longer logs at ERROR level. Fixes saltstack#51157
… probe The direct test calls _get_toplevel itself with ignore_retcode=True, the exact flag its production caller is_worktree passes when probing a path that may not be a repo, and asserts the flag is forwarded to cmd.run_all so the expected failure is not logged at ERROR level. The inverse test guards against overcorrection: callers like list_worktrees invoke _get_toplevel without the flag, and a genuine rev-parse failure there must still reach cmd.run_all with ignore_retcode=False and raise CommandExecutionError.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
What does this PR do?
git.is_worktree probes a directory with 'git rev-parse --show-toplevel' and expects retcode 128 for non-repos (already caught and handled), but _get_toplevel ran the probe without ignore_retcode so cmd.run_all logged the expected failure at ERROR level, producing the noisy "failed with return code: 128" messages reported in #51157. The fix adds an ignore_retcode parameter to _get_toplevel (default False, so the other caller at line ~2798 keeps failing loudly) and passes ignore_retcode=True from is_worktree's probe. Verified the fix works and that the test pins the bug: with the fix, is_worktree returns False and cmd.run_all is called with ignore_retcode=True; after stashing the source change, ignore_retcode is False, so the test assertion fails. Note: the pytest runner itself times out during salt's conftest/plugin collection in this shared venv even with --noconftest, so I validated the test's exact assertions by importing salt.modules.git directly with the identical mocks (fast, passes with fix / fails without).
What issues does this PR fix or reference?
Fixes #51157
Previous Behavior
See #51157.
New Behavior
Stop git.latest logging a spurious rev-parse error on first clone. Validated by a unit test proven to fail on unpatched 3006.x and pass with the fix (confirmed by adversarial review).
Merge requirements satisfied?
Commits signed with GPG?
No