Make number of polling attempts when starting a driver configurable
See original GitHub issueHi,
We’re trying to use the new UI tests feature (awesome feature!) at our jenkins builds and we ran into an issue that every couple of builds the test fails due to connection refused from port 9222.
When I check the chrome.log file it seems that the 5 seconds that the driver is waiting (250 milli * 20) was just not enough.
For example:
[centos@ip-10-121-51-213 build]$ cat chrome_1575942331669/chrome.log
01:45:31.671 poll attempt #0 for port to be ready - localhost:9222
01:45:31.671 sleeping for millis: 250
01:45:31.672 command: [/tmp/run_chrome_with_no_sandbox.sh, --remote-debugging-port=9222, --no-first-run, --user-data-dir=/home/centos/workspace/king-kong-pull-request/api-tests/build/chrome_1575942331669, --disable-popup-blocking, --headless]
01:45:31.673 env PATH: /home/centos/tools/hudson.model.JDK/OpenJDK-11/openjdk-11.0.4+11/bin:/usr/local/bin:/usr/bin:/usr/lib/gradle/gradle-3.1/bin
01:45:31.922 poll attempt #1 for port to be ready - localhost:9222
01:45:31.922 sleeping for millis: 250
01:45:32.173 poll attempt #2 for port to be ready - localhost:9222
01:45:32.174 sleeping for millis: 250
01:45:32.424 poll attempt #3 for port to be ready - localhost:9222
01:45:32.425 sleeping for millis: 250
01:45:32.675 poll attempt #4 for port to be ready - localhost:9222
01:45:32.676 sleeping for millis: 250
01:45:32.926 poll attempt #5 for port to be ready - localhost:9222
01:45:32.927 sleeping for millis: 250
01:45:33.177 poll attempt #6 for port to be ready - localhost:9222
01:45:33.178 sleeping for millis: 250
01:45:33.429 poll attempt #7 for port to be ready - localhost:9222
01:45:33.430 sleeping for millis: 250
01:45:33.680 poll attempt #8 for port to be ready - localhost:9222
01:45:33.680 sleeping for millis: 250
01:45:33.931 poll attempt #9 for port to be ready - localhost:9222
01:45:33.931 sleeping for millis: 250
01:45:34.182 poll attempt #10 for port to be ready - localhost:9222
01:45:34.182 sleeping for millis: 250
01:45:34.433 poll attempt #11 for port to be ready - localhost:9222
01:45:34.434 sleeping for millis: 250
01:45:34.684 poll attempt #12 for port to be ready - localhost:9222
01:45:34.685 sleeping for millis: 250
01:45:34.935 poll attempt #13 for port to be ready - localhost:9222
01:45:34.936 sleeping for millis: 250
01:45:35.186 poll attempt #14 for port to be ready - localhost:9222
01:45:35.187 sleeping for millis: 250
01:45:35.438 poll attempt #15 for port to be ready - localhost:9222
01:45:35.438 sleeping for millis: 250
01:45:35.689 poll attempt #16 for port to be ready - localhost:9222
01:45:35.689 sleeping for millis: 250
01:45:35.939 poll attempt #17 for port to be ready - localhost:9222
01:45:35.940 sleeping for millis: 250
01:45:36.194 poll attempt #18 for port to be ready - localhost:9222
01:45:36.195 sleeping for millis: 250
01:45:36.446 poll attempt #19 for port to be ready - localhost:9222
01:45:36.447 sleeping for millis: 250
01:45:39.325
DevTools listening on ws://127.0.0.1:9222/devtools/browser/0f3b38c7-d2bc-4c91-b115-258502cc16cb01:45:39.325 DevTools listening on ws://127.0.0.1:9222/devtools/browser/0f3b38c7-d2bc-4c91-b115-258502cc16cb
Any chance of making the number of attempts configurable?
I thought maybe to add under this line something like:
pollingAttempts = get("pollingAttempts", 19)
And then just replace the 19
in here with pollingAttempts
.
WDYS?
By the way, does the process starts after the configure driver...
line or only after Given driver...
? Because I tried adding some polling of my own, but no matter how long I wait it seems like i’m always a couple of seconds short, so I though that maybe the process only starts when we do Given driver....
and if that’s the case then I cant “interfere” in between. Am I correct?
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Will do! 😄
And yeah, i’m passing a custom executor (some bash file), that’s how i’m passing the
--fast-start
flag. At first I thought (hoped 😃 ) that it would be enough, but I tried like a dozen of different flags and none of them was able to make chrome consistently start fast enough.released 0.9.5