Conversation
|
Hi qxo, If I'm reading your changed correctly, you've added a "videoOn" capability to match nodes that are capable of recording videos, but also added another capability called "_videoOff" which controls whether the video node actually records a video? I can see why adding a new capability to tag the Selenium nodes would be useful (although it might be preferable if users configured this themselves - I'm open to a debate). If we also have a flag for the capability matcher to use to direct "videoOn: false" requests away from video nodes, I'm not sure why there would be an additional flag to disable recording capabilities. If the test knew in advance it didn't want a video, then it could send the request elsewhere - to a standard selenium node for example (which can support more browsers on a single node). Would you mind expanding on the above? Thanks, Alasdair |
|
Yes, "_videoOff" which controls whether the video node actually records a video or not. if selenium grid not use VideoOnCapabilityMatcher, Grid cant not send "videoOn: true" requests only to video nodes so we use two capability property and add a system property "seleniumVideoDefaultOff" ==> switch default recording off we grid change "capabilityMatcher" to "com.aimmac23.hub.proxy.VideoOnCapabilityMatcher" |
|
after 749be55 , videoOn=false was supported |
|
Hi qxo, I'm still a bit confused - if you had a test that didn't want to take a video, then surely you could create a session on a non-video capable node - which supports higher levels of test parallelism than this project? Why do you need to override the default behaviour of the video nodes? Thanks, Alasdair |
|
It's a feature for someone like me: use the video switchable node for selenium test. |
|
Hi qxo, Sorry to take so long to reply. I'm still confused - you could simply keep the video recording enabled, but don't read the video file when its generated? I'm a bit reluctant to merge the "_videoOff" part because standard selenium nodes support greater levels of parallelism than the video nodes do (since they don't care which window is on top), so instead of turning off video recording it would be better to send requests to the standard selenium nodes? The part involving the "videoOn" is a good idea (it would help you implement the above), and it could be useful to bundle a capability matcher for it in this project (for those who don't write Java). Thanks, Alasdair |
auto add "videoOn"="true" capability for VideoProxy enabled node so with "capabilityMatcher"="com.aimmac23.hub.proxy.VideoOnCapabilityMatcher" Grid could select suitable node and when request with capability ( "_videoOff":"true" ) on VideoProxy enabled node , video recording will not start origin commit: 8d72f4e
auto add "videoOn"="true" capability for VideoProxy enabled node
so with "capabilityMatcher"="com.aimmac23.hub.proxy.VideoOnCapabilityMatcher"
Grid could select suitable node
when request with capability ( "_videoOff":"true" ) on VideoProxy node recording will not start
Signed-off-by: qxo qxodream@gmail.com