0

Setup:

  • test framework around latest WebdriverIO v.7
  • Jenkins on GCP: master - Ubuntu, slave - Windows Server 2022 VM.
  • connection between Jenkins master and slave is done with GCP jenkins plugin, so Windows slave is being created for test and then dies.
  • app under test: Electron v14.2.1 based app.

Test - "User can start screenshare"

  1. User start a call.
  2. User select an available screen and start a screenshare.

Problem: Electron library can not detect available screen for capturing and sreensharing, because there is no RDP connection opened in test session.

In test logs no sources (screen) found:

2022-08-01 07:40:20:409 -00:00 | info | main-api-handler: - open-screen-picker-window - Properties: {
  "cmd": "open-screen-picker-window",
  "id": 1,
  "sources": []
}

Questions:

  1. How can the screen be emulated?
  2. Where the RDP should be established? Should it?
  3. Are there other way than RDP to provide the screen for the Electron app?
  • For Windows, you must have a license for each RDP connection (at least one). It is fairly easy to then grab a screenshot to distribute to multiple clients but that requires writing your own code. I am not aware of a method to emulate a screen short of writing your own video drivers (very complex task). I would look for a third-party app or library that does this for you. Today, there are many conference types of apps and libraries available. – John Hanley Aug 01 '22 at 20:48
  • Thanks, @JohnHanley for your comment, but what app/libs you are talking about? – Aleksandr Blatov Aug 08 '22 at 14:00
  • Google Search. I do not have any particular one to recommend. – John Hanley Aug 08 '22 at 18:54

1 Answers1

1

The problem was solved by my colleague:

"So the root cause of this issue is that the SSH server which Jenkins uses to configure the node runs as a service, and that means it has problems interacting with desktop apps. Unfortunately, Windows' own SSH server only runs as a service. More explanations here: Starting GUI programs via OpenSSH on Windows?

To resolve this, I installed a separate SSH server (OpenSSH from MSYS2). The machine image is configured to autologin on boot, and sshd is started on logon as the currently logged in user. This gives it access to the desktop, and screenshare tests now seem to work better"