Fix image tests: vncserver, websockify, jupyter-remote-desktop-proxy #101
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.
This is work done in parallell to #93, initially thought to be a quick fix to ensure TurboVNC also works. Like @yuvipanda in #93 I ran into issues with different behavior locally and within the GitHub actions environment, but think the biggest difference got resolved by providing a TTY device.
@yuvipanda I propose #93 is completed in a dedicated job inside the test.yaml workflow, side by side to the image-test job finalized in this PR - and then finally in an optional dedicated PR we prune misc bash things I've done in favor of python things you've done.
I consider this to fix #98, which was bugfixed by #99 but not tested by automation to make it work as it is now to some extent at least.
Summary of misc changes
websockify --help
andvncserver --help
checks--fail
flag to curl calls (detected by @yuvipanda in Add an integration test for VNC + websockify #93)vncserver
being startedA blob of old notes, I've worked a lot of hours 😱
Debugging the same issue Yuvi ran into I think:
I've debugged this at length with minor progress.
First attempt failure
I've concluded that the initial websocket connection attempt often fails to get sensible responses etc, and I think this relates to jupyter-server-proxy finalizes a websocket handshake even if the handshake to the backend isn't finalized (jupyterhub/jupyter-server-proxy#459). But this shouldn't cause issues for the second attempt that typically works locally.
Future attempt failures
The difference I observe locally and remote, comes down to this, where the green parts represent local and red parts represents failing remote test runs in github actions.
(ignore timestamps, this is a composed set of log lines)
websocat output
jupyter_server logs
websockify logs
vncserver logs