-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
#2592: Fixes unit tests dependent on echo on windows #2602
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
# Make sure that the pager gets executed | ||
--paging=always | ||
|
||
# Output a dummy message for the integration test and system wide config test. | ||
--pager="echo.bat dummy-pager-from-config" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
ECHO %* |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,11 +17,16 @@ fn get_mocked_pagers_dir() -> PathBuf { | |
/// On Unix: 'most' -> 'most' | ||
/// On Windows: 'most' -> 'most.bat' | ||
pub fn from(base: &str) -> String { | ||
if cfg!(windows) { | ||
format!("{}.bat", base) | ||
} else { | ||
String::from(base) | ||
let mut cmd_and_args = shell_words::split(base).unwrap(); | ||
let suffix = if cfg!(windows) { ".bat" } else { "" }; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since we already depend on There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done, refactored it a bit further as well. |
||
let mut out_cmd = format!("{}{}", cmd_and_args.first().unwrap(), suffix); | ||
|
||
if (cmd_and_args.len() > 1) { | ||
out_cmd.push(' '); | ||
out_cmd.push_str(cmd_and_args[1..].to_vec().join(" ").as_str()); | ||
} | ||
|
||
out_cmd | ||
} | ||
|
||
/// Prepends a directory to the PATH environment variable | ||
|
@@ -62,6 +67,11 @@ pub fn with_mocked_versions_of_more_and_most_in_path(actual_test: fn()) { | |
.assert() | ||
.success() | ||
.stdout(predicate::str::contains("I am most")); | ||
Command::new(from("echo")) | ||
.arg("foobar") | ||
.assert() | ||
.success() | ||
.stdout(predicate::str::contains("foobar")); | ||
|
||
// Now run the actual test | ||
actual_test(); | ||
|
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.
Thank you for your contribution. I don't quite follow along here though. Why do we need to change for example this
pager_basic()
test?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.
You're welcome. The reason we're using the mocked versions here, is so that we actually have an
echo
available for powershell. See my comment on the original bug report: #2592.echo
is not resolved, so on powershell tests that rely on it fail.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.
That makes sense. I never tried to run
cargo test
in PowerShell on Windows before. But now when I do these tests indeed fail. Any chance you would be willing to look into running our tests in CI in PowerShell on Windows? Some instructions: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-powershellIn our
.github\workflows\CICD.yml
andmatrix:
I think we would want to parameterize onshell:
so that Windows tests run withshell: pwsh
. Unless we continuously run the tests in PowerShell, it will for sure break again without anyone not noticing.If you are not interested in doing this, that's totally fine. Just let me know, and I will do a more detailed review of this PR as it is.
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.
Sure, I don't mind taking a look. Do you want it as part of this PR?
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.
Great! Yes I think that would be good, that way we know the tests pass in CI PowerShell before we merge.
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.
@Enselic After taking a quick look at the test output and code, I am not entirely sure what the cause is.
Also, strangely, if I only run the integration tests with
cargo test --test integration_tests
it does not appear to fail on my system. Even when running it repeatedly usingchronic
from moreutils.If I had to make an educated guess, it's some sort of data race that's interfering with
$LESSCLOSE
. Likely by either keeping it from executing or by just preventing its output from reaching the test runner. I am not sure if it is related to the stdin and temp file parts of the test or if it's just a matter of whencargo
runs it relative to the other tests.I'll try to take a closer look later when I get a chance, but I am honestly not even sure how to go from here.
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 can't reproduce any flakiness unfortunately. Not in WSL 2 nor in PowerShell.
@boyvanduuren Feel free to add an
#[ignore = "failing intermittently on some systems"]
in your PR for now.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.
All green.
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.
@boyvanduuren Thanks
@Anomalocaridid: if I run that test "manually", I get an error message from
less
:Could this be the issue? Maybe the race condition is somehow related to whether or not that error is printed first.
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.
@sharkdp Possibly? However, it looks like that error also appears when manually running the other tests where
$LESSCLOSE
has a dash as part of its prefix. But those do not have the same issue, right?A recent comment on my PR for
$LESSOPEN
support gave me a helpful lead.Basically, they said that the files were going through
$LESSOPEN
twice, through bothbat
andless
. Sure enough, by running the test manually withless
instead of bat, the sameLESSOPEN ignored
message appears. Also it may be worth mentioning that the message is not present in the code for bat's$LESSOPEN
implementation.So for some reason, the
$LESSOPEN
environment variable is being passed on toless
, but only when$LESSOPEN
has a dash in it that indicates that stdin is to be preprocessed as well as files.When I get a chance, I'll try to fix both
$LESSOPEN
being passed toless
as well as makebat
more closely matchless
's behavior for$LESSOPEN
without a%s
.