Integration test failures during Arch Linux build #93
Comments
|
Huh, thanks for the report. So seems like that is coming from the stderr of the app, and not from any of the test code. Is it possible to run just the app in the chroot environment with something like # so that the environment is similar to the tests
$ mkdir /tmp/test
$ cd /tmp/test
# The PWD can maybe left out? Not sure. But this is effectively what I do in the test.
$ PWD=/tmp/test /path/to/tere &> test-out.txt
<press ctrl-c or esc to exit if necessary>
$ PWD=/tmp/test /path/to/tere 2> test-out-stderr.txt 1> test-out-stdout.txt
<press ctrl-c or esc to exit if necessary>Could you do this and tell me what's in the txt files, including control codes? Or what is the output of the app if you just run it without redirecting the output? Another option is to try to add a test to #[test]
fn dummy() -> Result<(), RexpectError> {
let mut proc = run_app_with_cmd(get_cmd_no_first_run_prompt());
proc.send_control('c')?;
proc.writer.flush()?;
let output = proc.exp_eof()?;
println!("{:?}", output);
assert!(false);
}And check the stdout of that, does it have some more info than " |
$ PWD=/tmp/test tere &> test-out.txt # exit code: 1
$ cat test-out.txt
Cancelled.$ PWD=/tmp/test tere 2> test-out-stderr.txt 1> test-out-stdout.txt # exit code: 1
$ cat test-out-stderr.txt
Cancelled.
$ cat test-out-stdout.txt
# empty
It runs normally.
Output
Ah, good catch. However, it is mounted inside chroot: $ findmnt
├─/dev tmpfs tmpfs rw,nosuid,size=4096k,nr_inodes=65536,mode=755,inode64
│ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev,size=26378176k,nr_inodes=409600,inode64
│ ├─/dev/pts devpts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 |
|
Thanks for testing this! I'll look into it. One thing to note that |
|
I searched a bit more and found some discussion suggesting that this error may show up in Rust if the thread limit is reached or there isn't enough memory. Is it possible that the no. of threads in chroot mode is limited? Does the error go away if you run |
|
Also, what is the output of the failing test if you change this line to |
This time I got:
|
|
Huh, where is that "No such file or directory" error now suddenly coming from? Do you reliably get the results you had previously ( The second set of results you have with the |
|
Hey, I just took a look at this again and I'm totally lost as well. I don't remember the last thing that I tried but if I try to build again I get this failure: I think I'm just going to close my eyes and keep skipping tests. Sorry for this extremely annoying issue 😅 |
|
No worries. I thought about the async thing a little bit too but didn't get anywhere. However! Now I tried the tests as well and the same test fails for me, and it seems reproducible. So that's probably a real test failure. |
|
I did a bisect and that test fails for me for all commits after reworking the tests to use real folders instead of just a list of strings in 6d7eb28 and c90c497. I'm pretty sure I would have fixed this if it had shown up. So something has changed, maybe something with the compiler version or dependencies, both of which are kind of worrisome. |
Not sure why it was broken in the first place... See also discussion in Github issue #93
|
I now fixed it in 8cadf56, this |
|
NixOS updates finally hit this problem. I couldn't see any broken functionality so I commented out the failing tests. NixOS/nixpkgs#298489 |
|
Thanks @ProducerMatt for the report! Which version of rustc/cargo do you have on Nix? I still can't reproduce this on Fedora 38 with rustc 1.75.0. With Nix it sounds like I might be able to reproduce this issue. Is there a way to set up a minimal environment without installing the full NixOS? |
|
@mgunyho yes in fact, Nix runs on other Linux and MacOS. I will submit a PR with a Nix dev environment and how to use it. :) |
|
Nix environment submitted. #100 |
|
With the help of @ProducerMatt's nix environment in #100, I managed to track down the issue. It's the let file = File::open("/dev/tty").map(|file| (FileDesc::new(file.into_raw_fd(), true)));
let fd = if let Ok(file) = &file {
file.raw_fd()
} else {
// Fallback to libc::STDOUT_FILENO if /dev/tty is missing
STDOUT_FILENO
};
if wrap_with_result(unsafe { ioctl(fd, TIOCGWINSZ.into(), &mut size) }).is_ok() {
return Ok(size.into());
}
Err(std::io::Error::last_os_error().into())The first part sets After this, it calls So the problem is querying the "terminal size" inside the Nix environment / chroot. The next step would be to flood my search engine with queries like "nix environment tty" and similar. |
|
Nice! I'm glad we now know the root cause of the issue. FWIW there are libraries such as |
|
@orhun Could you try to run the tests with |
|
Good tip! I only get a single failure now: It might be better to use |
|
That is actually another failure that has been fixed on the BTW, based on the readme of |
|
I'm starting to think that it would be easiest to just skip the integration tests for now, this can be done by changing the test command to |
|
Everything is good with the following command: $ script -e -c "cargo test --frozen -- --skip test_case_sensitive_mode_change"I didn't test Using
This also makes sense to me. |
|
This is with the chroot? Good to hear if it works. |
|
Yup, that's inside chroot! I can take a stab at doing this with |
|
Alright, sounds good! You can pick whichever of |
|
Okay, I found a solution that doesn't rely on |
|
Wow, nice discovery. And good news, yes that worked like a charm! 🎉 No |
|
Alright, cool! I'll close this issue for now, let me know if anything else comes up. We can remove the |
|
Thanks for bearing with me on this! |
Integration tests were added in the last release, more specifically: 70d2686
I'm getting the following test failures in a clean chroot build:
I couldn't figure out why this is happening so I thought it'd better to report here.
As a workaround, I tried skipping the integration tests and using
--libbut goterror: no library targets found in package tere.The text was updated successfully, but these errors were encountered: