Closed Tachi107 closed 1 year ago
The test doesn't currently pass, and won't pass until my suggestion of lowering the default TLS handshake timeout is applied, which is the only way to make the test source-compatible with unpatched versions.
I can also add a test checking a non-default timeout though
This looks great @Tachi107. But it looks like the listener_tls_test
test isn't being run in CI?
Yeah, the library is built without TLS support in CI. I can add a job that compiles that variant too
And autopkgtest is failing because we have a patch in the debian
branch which disables GMock 1.11 because it's unavailable in old Ubuntu versions we support. I can tweak that patch as well.
Ok perfect. I didn't realize that we didn't test in CI without TLS. Is there any reason why we don't do this? Presumably that would exhaust more code paths.
I've pushed https://github.com/pistacheio/pistache/commit/ad946ec5ed458963ba85878c19a60c4d9856a202 which should fix the autopkgtest issue
Looks like there's also some missing dependencies for the clang CI:
ld.lld: error: cannot open /usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.asan_static-x86_64.a: No such file or directory
ld.lld: error: cannot open /usr/lib/llvm-14/lib/clang/14.0.6/lib/linux/libclang_rt.profile-x86_64.a: No such file or directory
Looks like there's also some missing dependencies for the clang CI
That's because of recent changes in the llvm-toolchain-14
Debian package, I'll add the required dependency on libclang-rt-dev
Edit: done
Base: 78.38% // Head: 78.45% // Increases project coverage by +0.07%
:tada:
Coverage data is based on head (
2249d6c
) compared to base (05deeb4
). Patch has no changes to coverable lines.:exclamation: Current head 2249d6c differs from pull request most recent head a8d660c. Consider uploading reports for the commit a8d660c to get more accurate results
:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
I also took some time to fix the RHEL 8 job. The ninja binary installed with pip3 was somehow malfunctioning on that RHEL version (ninja --version
reported the correct value, but then exited with status 245, never seen before), and installing the official binaries fixed the issue. Odd.
Anyway, the autopkgtest job is now correctly failing, signalling that the new test is working.
Great work @Tachi107. @dennisjenkins75 are you fine with this?
The test has a 20s pause in it? I didn't see a call to set the timeout when creating the server. Can you set the server to timeout after a shorter period, maybe 3s; and the have the test check after 5s? Waiting 20s seems like a long time dor a unit test to nap.
Otherwise, it seems fine.
@dennisjenkins75 the test checks that the default TLS handshake timeout (which should be 10 seconds, but currently is 60) is less than 20 seconds.
I'll add another test that sets a custom timeout of e.g. 3 seconds and checks that it actually is three seconds.
I've pushed a commit containing a test which uses the API I proposed in #1115, which obviously does not compile yet
Nice job @Tachi107. I'm fine with this. Feel free to merge if you're comfortable with your work as well.
With #1115 merged @Tachi107, are you ready to merge the unit test?
Just a sec, I'd like to first rebase onto the master branch to see the tests pass
In case it helps, there are some build dependency problems I am seeing when I try to run locally in autopkgtest
, but your changes may have already fixed this. I haven't looked too deeply into it:
...
dpkg-buildpackage: info: source package pistache
dpkg-buildpackage: info: source version 0.0.5-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Kip Warner <kip@thevertigo.com>
dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 13) meson (>= 0.50.0) libcurl4-openssl-dev libgmock-dev (>=v
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
autopkgtest [12:06:04]: - - - - - - - - - - running shell - - - - - - - - - -
You can now log into the VM through the serial terminal.
Depending on which terminal program you have installed, you can use one of
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022 ubuntu@localhost
minicom -D unix#/tmp/autopkgtest-qemu.y9mdg6p9/ttyS0
nc -U /tmp/autopkgtest-qemu.y9mdg6p9/ttyS0
socat - UNIX-CONNECT:/tmp/autopkgtest-qemu.y9mdg6p9/ttyS0
The tested source package is in /
Press Enter to resume running tests.
Are you able to verify on your end?
Which reminds me, we need to bump the version in debian/changelog
.
In case it helps, there are some build dependency problems I am seeing when I try to run locally in
autopkgtest
, but your changes may have already fixed this. I haven't looked too deeply into it:dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper-compat (= 13) meson (>= 0.50.0) libcurl4-openssl-dev libgmock-dev (>=v
Are you able to verify on your end?
Uhm, I'm not sure this is related to this pr. How are you running autopkgtest? What virt-server (e.g. podman, chroot, lxc...) are you using?
Which reminds me, we need to bump the version in
debian/changelog
.
Yeah, I wonder if we can automate it.
All tests passed, merging
Uhm, I'm not sure this is related to this pr. How are you running autopkgtest? What virt-server (e.g. podman, chroot, lxc...) are you using?
It's probably not related. I'm running autopkgtest via QEMU with KVM enabled. Here is my configuration:
--shell-fail
--apt-upgrade
--setup-commands=/home/kip/Projects/sbuild/scripts/setup.sh
--
qemu
--ram-size=8192
--cpus=8
--show-boot
/home/kip/Projects/sbuild/images/autopkgtest-jammy-amd64.img
--qemu-options=-enable-kvm
Can we continue on IRC?
The new
tls_handshake_timeout
test is source-compatible with Pistache versions with and without the fix in #1115, so that it is easy to test if the bug reproduces with and without that patch applied.