Skip to content
This repository has been archived by the owner on Jun 30, 2021. It is now read-only.

Empty pool of VM for setup Capabilities #296

Closed
2 tasks done
thorsteneckel opened this issue Dec 18, 2018 · 26 comments · Fixed by #320
Closed
2 tasks done

Empty pool of VM for setup Capabilities #296

thorsteneckel opened this issue Dec 18, 2018 · 26 comments · Fixed by #320

Comments

@thorsteneckel
Copy link

thorsteneckel commented Dec 18, 2018

Hi there 👋Thanks a lot for this great docker image 🐳

We over at Zammad use your image in our GitLab CI env. In a bit more than 1% of all runs jobs fail with the following error message (in /var/log/cont/selenium-hub-stderr.log):

18:33:45.600 INFO [Hub.start] - Clients should connect to http://172.17.0.24:24444/wd/hub
18:34:11.096 INFO [RequestHandler.process] - Got a request to create a new session: Capabilities {browserName: firefox, cssSelectorsEnabled: true, idleTimeout: 300, javascriptEnabled: true, nativeEvents: false, rotatable: false, takesScreenshot: true, version: }
18:34:11.097 INFO [RequestHandler.process] - Error forwarding the new session Empty pool of VM for setup Capabilities {browserName: firefox, cssSelectorsEnabled: true, idleTimeout: 300, javascriptEnabled: true, nativeEvents: false, rotatable: false, takesScreenshot: true, version: }
org.openqa.grid.common.exception.GridException: Empty pool of VM for setup Capabilities {browserName: firefox, cssSelectorsEnabled: true, idleTimeout: 300, javascriptEnabled: true, nativeEvents: false, rotatable: false, takesScreenshot: true, version: }
	at org.openqa.grid.internal.ProxySet.verifyAbilityToHandleDesiredCapabilities(ProxySet.java:146)
	at org.openqa.grid.internal.DefaultGridRegistry.addNewSessionRequest(DefaultGridRegistry.java:217)
	at org.openqa.grid.web.servlet.handler.RequestHandler.process(RequestHandler.java:111)
	at org.openqa.grid.web.servlet.DriverServlet.process(DriverServlet.java:85)
	at org.openqa.grid.web.servlet.DriverServlet.doPost(DriverServlet.java:69)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.seleniumhq.jetty9.servlet.ServletHolder.handle(ServletHolder.java:865)
	at org.seleniumhq.jetty9.servlet.ServletHandler.doHandle(ServletHandler.java:535)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.handle(ScopedHandler.java:146)
	at org.seleniumhq.jetty9.security.SecurityHandler.handle(SecurityHandler.java:548)
	at org.seleniumhq.jetty9.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)
	at org.seleniumhq.jetty9.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)
	at org.seleniumhq.jetty9.server.handler.ContextHandler.doHandle(ContextHandler.java:1340)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)
	at org.seleniumhq.jetty9.servlet.ServletHandler.doScope(ServletHandler.java:473)
	at org.seleniumhq.jetty9.server.session.SessionHandler.doScope(SessionHandler.java:1564)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)
	at org.seleniumhq.jetty9.server.handler.ContextHandler.doScope(ContextHandler.java:1242)
	at org.seleniumhq.jetty9.server.handler.ScopedHandler.handle(ScopedHandler.java:144)
	at org.seleniumhq.jetty9.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
	at org.seleniumhq.jetty9.server.Server.handle(Server.java:503)
	at org.seleniumhq.jetty9.server.HttpChannel.handle(HttpChannel.java:364)
	at org.seleniumhq.jetty9.server.HttpConnection.onFillable(HttpConnection.java:260)
	at org.seleniumhq.jetty9.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305)
	at org.seleniumhq.jetty9.io.FillInterest.fillable(FillInterest.java:103)
	at org.seleniumhq.jetty9.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118)
	at org.seleniumhq.jetty9.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)
	at org.seleniumhq.jetty9.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)
	at org.seleniumhq.jetty9.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
	at org.seleniumhq.jetty9.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
	at org.seleniumhq.jetty9.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765)
	at org.seleniumhq.jetty9.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683)
	at java.lang.Thread.run(Thread.java:748)

I noticed a differences between a regular run in (and only) the selenium-hub-stderr.log: The two Registered a node lines are missing.

19:05:36.380 INFO [Hub.start] - Clients should connect to http://172.17.0.4:24444/wd/hub
19:05:42.648 INFO [DefaultGridRegistry.add] - Registered a node http://172.17.0.4:25551
19:05:42.675 INFO [DefaultGridRegistry.add] - Registered a node http://172.17.0.4:25550

The timestamps look like as if there might be a race condition between registering the nodes and requesting a new session. However, I started debugging and found out that (after the failing "new session" request) no new sessions can be generated - wether firefox nor chrome - even after 10 minutes and more.

After googling around I found issue #64 - which is now more than 2 years old. Back in the days @elgalu wrote to use docker exec selenium wait_all_done 30s which now seems to be deprecated.

GitLab CI uses a HEALTHCHECK (which shouldn't be available in the first place?) to check the containers but logs the following for selenium on every run (successful and unsuccessful):

*** WARNING: Service runner--project-0-concurrent-0-docker.io__elgalu__selenium-2 probably didn't start properly.

Health check error:
exit code 1

Health check container logs:
2018-12-18T19:05:30.858410900Z No HOST or PORT

Service container logs:
2018-12-18T19:05:28.231944600Z --LOG 19:05:28:229916500 Stopping supervisord to support docker restart...
2018-12-18T19:05:29.697086600Z -- INFO: Docker Img. Version: 3.141.59-291
2018-12-18T19:05:29.697151800Z -- INFO: Chrome..... Version: 70.0.3538.110
2018-12-18T19:05:29.697352600Z -- INFO: Firefox.... Version: 63.0.3
2018-12-18T19:05:29.698269500Z -- INFO: Using Selenium.....: 3.141.59
2018-12-18T19:05:30.522211500Z ***************** BEGIN: Data Processing Agreement *****************
2018-12-18T19:05:30.522251600Z By using this software you agree that the following non-PII
2018-12-18T19:05:30.522293400Z (non personally identifiable information) data will be collected,
2018-12-18T19:05:30.522333900Z processed and used by Docker-selenium for the purpose of improving
2018-12-18T19:05:30.522376900Z our test infrastructure tools. Anonymisation with respect of the IP
2018-12-18T19:05:30.522413800Z address means that only the first two octets of the IP address are
2018-12-18T19:05:30.522570200Z collected. See the complete license at:
2018-12-18T19:05:30.522643300Z https://github.com/elgalu/docker-selenium/blob/master/LICENSE.md
2018-12-18T19:05:30.522680800Z ****************** END: Data Processing Agreement ******************
2018-12-18T19:05:31.508757900Z supervisord --version=4.0.0.dev0
2018-12-18T19:05:32.045551600Z 2018-12-18 19:05:32,044 INFO Included extra file "/etc/supervisor/conf.d/novnc.conf" during parsing
2018-12-18T19:05:32.045634000Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/selenium-hub.conf" during parsing
2018-12-18T19:05:32.045663000Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/selenium-multinode.conf" during parsing
2018-12-18T19:05:32.045699000Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/selenium-node-chrome.conf" during parsing
2018-12-18T19:05:32.045726400Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/selenium-node-firefox.conf" during parsing
2018-12-18T19:05:32.045760000Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/video-rec.conf" during parsing
2018-12-18T19:05:32.045788000Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/vnc.conf" during parsing
2018-12-18T19:05:32.045813300Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/xmanager.conf" during parsing
2018-12-18T19:05:32.045982300Z 2018-12-18 19:05:32,045 INFO Included extra file "/etc/supervisor/conf.d/xterm.conf" during parsing
2018-12-18T19:05:32.058912200Z 2018-12-18 19:05:32,058 INFO RPC interface 'supervisor' initialized
2018-12-18T19:05:32.060213800Z 2018-12-18 19:05:32,058 INFO RPC interface 'supervisor' initialized
2018-12-18T19:05:32.060790900Z 2018-12-18 19:05:32,060 INFO supervisord started with pid 165

*********

However, I was wondering how to approach this these days? How can I resolve this?

I have collected all the logs I could get but found no valuable lines (in my eyes) except the ones I posted. Please let me know if you need any of the others.

Looking forward to read from you 👋

Operating System

  • Darwin MacBookPro 2016 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
  • Linux CI ENV 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Image version

  • I have latest version of this image. Upgrade with docker pull elgalu/selenium

Docker version

  • I have latest version of docker and I will specify here the output of docker --version: Docker version 18.09.0, build 4d60db4
@diemol
Copy link
Collaborator

diemol commented Dec 18, 2018

Hi @thorsteneckel,

You can check the /wd/hub/status endpoint in the hub, where you should get something like this:

{
  "status": 0,
  "value": {
    "ready": true,
    "message": "Hub has capacity",
    "build": {
      "revision": "aacccce0",
      "time": "2018-08-02T20:13:22.693Z",
      "version": "3.14.0"
    },
    "os": {
      "arch": "amd64",
      "name": "Linux",
      "version": "4.9.93-linuxkit-aufs"
    },
    "java": {
      "version": "1.8.0_181"
    }
  }
}

and when "ready": equals to true, that means that the Grid has nodes registered to handle incoming requests.

@thorsteneckel
Copy link
Author

Hi @diemol - thanks for your fast reply. That's great to know! I wrote a small test script that requests a new session (via Selenium::WebDriver.for(:remote, desired_capabilities: Selenium::WebDriver::Remote::Capabilities.chrome)) in a loop while the docker container is booting up:

I get this exception (from the ruby context) while the server hasn't started yet:

EOFError: end of file reached

Next exception I get is the one described in my first comment (nice!):

Selenium::WebDriver::Error::UnknownError: Error forwarding the new session Empty pool of VM for setup Capabilities {browserName: chrome, cssSelectorsEnabled: true, javascriptEnabled: true, nativeEvents: false, rotatable: false, takesScreenshot: false, version: } (org.openqa.grid.common.exception.GridException)

This is where the Selenium server usually gets stuck in my scenario. However, as opposed to the situation described in the first comment my local test gets through after a few seconds and successfully creates a session 🤔

I'll now try to fetch the wd/hub/status endpoint before creating the session as an attempt to avoid getting the server stuck in the first place.

@thorsteneckel
Copy link
Author

So I did as described and wrote a little test script (see below). Unfortunately the /wd/hub/status returns for more than 10 minutes No spare hub capacity. The script dies after that 10 minute timeout. I can reproduce it by running 200 jobs - about 3 of them are failing with that error.

Any thoughts on what to try/debug next? Help is greatly appreciated.

Here is the script:

http_client = Selenium::WebDriver::Remote::Http::Default.new(
  open_timeout: 120,
  read_timeout: 120
)

uri                    = URI.parse(ENV['REMOTE_URL'])
uri.path              += '/' unless uri.path.end_with?('/')
http_client.server_url = uri

Timeout.timeout(10.minutes) do
  begin
    loop do
      response = http_client.call(:get, 'status', {})

      if !response['status'].zero?
        puts "Got unexpected response: #{response}"
        next
      end

      break if response['value']['ready']

      puts "Not ready yet: #{response['value']['message']}"
    end
  rescue EOFError
    puts "Server started but status endpoint isn't ready yet"
    retry
  rescue Errno::ECONNREFUSED
    puts 'Server is down'
    retry
  end
end

puts 'Ready to roll 🚀'

OT: @diemol - if you are into stickers make sure to write a mail to contact@zammad.com and refer to me. We will send you some!

@diemol
Copy link
Collaborator

diemol commented Dec 19, 2018

That's strange, we use that approach widely, as a smoke test to see that the Grid is up. We documented it a bit more in the official images here. We just normally start the images (via docker-compose or just docker commands) and then use the script to wait for it.


Thanks for offering the stickers! I see you are in Berlin, I am also helping to organise the Berlin Selenium Meetup, and I'd like to do one in February 2019... Maybe you would like to show how you do testing at Zammad? (Or any topic related to testing that you might want to show :))

@thorsteneckel
Copy link
Author

I totally agree. There's nothing special about the setup and 99% of the jobs run smoothly, perfectly fine. However, if there is anything I can do debug this further (by myself) please let me know. I think I didn't mention it earlier but I got access to the container in the broken state and can execute commands and everything.


Wow - thanks for the invitation. I'd love to! Actually we just finished the pretty big migration (by our standard) of our GitLab CI SSH runners to docker powered containerization and there's always some knowledge to share. Our comprehensive Selenium/browser test suite took a big part in it. Don't hesitate to get in touch via contact@zammad.com and refer to me.

@andrejska
Copy link

andrejska commented Jan 4, 2019

Guys, I am experiencing same issue, as described here problem is that for some reasons chrome node is starting to connect and gets stuck
bad scenario:

        15:50:25.120 INFO [SeleniumServer.boot] - Selenium Server is up and running on port 25550
        15:50:25.120 INFO [GridLauncherV3.lambda$buildLaunchers$7] - Selenium Grid node is up and ready to register to the hub
        15:50:25.179 INFO [SelfRegisteringRemote$1.run] - Starting auto registration thread. Will try to register every 5000 ms.
        15:50:25.527 INFO [SelfRegisteringRemote.registerToHub] - Registering the node to the hub: http://127.0.0.1:24444/grid/register

good scenario:

15:52:27.549 INFO [GridLauncherV3.lambda$buildLaunchers$7] - Launching a Selenium Grid node on port 25550
2019-01-03 15:52:27.667:INFO::main: Logging initialized @521ms to org.seleniumhq.jetty9.util.log.StdErrLog
15:52:27.902 INFO [WebDriverServlet.<init>] - Initialising WebDriverServlet
15:52:27.990 INFO [SeleniumServer.boot] - Selenium Server is up and running on port 25550
15:52:27.990 INFO [GridLauncherV3.lambda$buildLaunchers$7] - Selenium Grid node is up and ready to register to the hub
15:52:28.036 INFO [SelfRegisteringRemote$1.run] - Starting auto registration thread. Will try to register every 5000 ms.
15:52:28.352 INFO [SelfRegisteringRemote.registerToHub] - Registering the node to the hub: http://127.0.0.1:24444/grid/register
15:52:28.417 INFO [SelfRegisteringRemote.registerToHub] - The node is registered to the hub and ready to use

I am experiencing this issue with latest docker-selenium bundle - selenium:3.141.59
Before that I have never seen such problem
On CI, which uses gitlab k8s runner it happens in 5%, I also managed to repeat it locally with docker (tried about 10-15 times):

docker run -d --name=grid -p 4444:24444 -p 5900:25900 -e TZ="US/Pacific" -v /dev/shm:/dev/shm --privileged elgalu/selenium:3.141.59-p6
docker exec -it grid cat /var/log/cont/selenium-node-chrome-stderr.log <-- waiting for message
docker rm -f grid

What can I do to debug this issue?

@thorsteneckel
Copy link
Author

If it's of any interest - we're using a custom TZ (Europe/London), too.

@andrejska - no new information/progress from my side. Sill happening in about 1% of the runs.

Would be interesting which processes are not starting correctly. Maybe some strace debugging might help.

@diemol
Copy link
Collaborator

diemol commented Jan 17, 2019

Hi again, sorry for the late reply (holidays and family matters during these weeks).
A few things:

  • Could you please post how you start the docker images?
  • Can we get the logs of the hub and the node when the issue happens?
  • If I understand correctly, this happens either in Mac or Linux, right?

@diemol
Copy link
Collaborator

diemol commented Jan 17, 2019

Side node @thorsteneckel, just sent an email about the Selenium Meetup to contact@zammad.com :)
Actually I resent it to enjoy@zammad.com since the other address didn't work.

@thorsteneckel
Copy link
Author

Hi @diemol - no need to feel sorry. There is nothing we can ask from you. I hope you had a good time.

Could you please post how you start the docker images?

In our case it's done automatically by the GitLab CI runner. However, I could verify the steps @andrejska posted locally. It took me about 20 tries.

Can we get the logs of the hub and the node when the issue happens?

Sure. you can find everything from the /var/logs/cont directory here. Please note that these files are back from early December. If you need other or updated files just let me know.

If I understand correctly, this happens either in Mac or Linux, right?

I can reproduce it on Linux (CoreOS, CentOS, Ubuntu) and Mac giving it enough tries.

Thanks for your help and email! I already replied and noted in my head that enjoy is the right one 💡

@diemol
Copy link
Collaborator

diemol commented Jan 23, 2019

How do you reproduce it on a Mac? I was trying but I haven't bumped into it... Could you share the command you used to reproduce?

@thorsteneckel
Copy link
Author

I wrote a little ruby script (tested with ruby 2.4.4p296 (2018-03-28 revision 63013) [x86_64-darwin17]) to reproduce the issue. All you need to do is to install the selenium webdriver gem (via gem install 'selenium-webdriver') and run the script afterwards via ruby empty_pool_provoker.rb.

The output looks like this:

ruby empty_pool_provoker.rb 
Welcome 👋
HUB URL: http://localhost:4444/wd/hub
Daemonizing command: docker run --rm -ti -d --name=service-selenium -p 4444:24444 -p 5900:25900 -v /dev/shm:/dev/shm --privileged docker.io/elgalu/selenium:latest
Stop command: docker stop service-selenium
Starting work 🚧
------------------------------------------------------------------------------------------
Try #1
Daemonizing...DONE!
Server started but status endpoint isn't ready yet
Not ready yet: No spare hub capacity
Container started properly. Shutting down and retry.
Stopping...DONE!
------------------------------------------------------------------------------------------
...
Try #24
Daemonizing...DONE!
Server started but status endpoint isn't ready yet
Not ready yet: No spare hub capacity
Issue reproduced. Container is wanted state. You can now connect into it (e.g. via `docker exec -ti service-selenium /bin/bash`)

As stated in the output you can enter the container via docker exec -ti service-selenium /bin/bash.

You can set the following ENVs if you need to use other commands/URLs etc. I added the default values. The used values get printed in the header output:

TIMEOUT = 60 
HUB_URL = 'http://localhost:4444/wd/hub'
DAEMONIZING_COMMAND = 'docker run --rm -ti -d --name=service-selenium -p 4444:24444 -p 5900:25900 -v /dev/shm:/dev/shm --privileged docker.io/elgalu/selenium:latest'
STOP_COMMAND = 'docker stop service-selenium'

I noticed this time that the container has a pretty high load and seems to be in an endless loop. See the docker stats output:

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
a245b57bf056        service-selenium    202.48%             422.9MiB / 15.65GiB   2.64%               2.31MB / 3.12MB     0B / 131kB          125

ps aux inside of the container revealed that the /home/seluser/selenium-server-standalone-3.jar takes all the CPU it can get:

seluser 208 200 0.9 17462768 152684 pts/0 Sl 11:32 18:55 java -Xmx13127513k -jar /home/seluser/selenium-server-standalone-3.jar -port 24444 -role hub -m...

Let me know if you need anything further.

@diemol
Copy link
Collaborator

diemol commented Feb 6, 2019

Hi everyone, just reporting here again, currently I am trying @thorsteneckel's ruby script, will report back with my findings during the day.

@diemol
Copy link
Collaborator

diemol commented Feb 6, 2019

OK, issue reproduced, now adding -e SELENIUM_NODE_PARAMS="-debug" -e SELENIUM_HUB_PARAMS="-debug" to the start command and see what the logs show us.

@diemol
Copy link
Collaborator

diemol commented Feb 6, 2019

Sadly the debug log does not reveal anything special, it just shows the two registration requests from the nodes and then @andrejska mentions, the CPU usage goes up to the roof.

I'll try to debug a bit more to see if I find something particular.

@diemol
Copy link
Collaborator

diemol commented Feb 6, 2019

Do you guys know when this started to happen? Is it possible for you to pin a specific release? @thorsteneckel @andrejska

@thorsteneckel
Copy link
Author

Hi @diemol - thanks for your efforts so far! Unfortunately I can't pin it down. It started while migrating our CI to use docker instead of a local Selenium installation. This was in November, maybe October. So we "always" had this issue. My colleagues are using the docker image in other, smaller projects from time to time for quite a while but I never heard of it before. It may have never happed on that smaller scale.

I was looking around and thinking of a way to help. There is a great profiler called rbspy for ruby that gives you a flame graph / stack trace of a running ruby script. Unfortunately my Java days are long gone and I wasn't able to find anything similar for Java :/

So I'm no help here. If there's anything I can contribute, please let me know.

@diemol
Copy link
Collaborator

diemol commented Feb 11, 2019

I think the root cause is this issue SeleniumHQ/selenium#6918

But we have to see what we can do because ideally we are not going to release anything else after 3.141.59

@thorsteneckel
Copy link
Author

It would be fine for me to use an older version of elgalu/docker-selenium which uses 3.14.0 under the hood to see if it's actually this issue. Would this help you? Can you tell me which elgalu/docker-selenium version this would be or where I can find the information?

@thorsteneckel
Copy link
Author

After having a look at the version information and tags of this repo/image it's pretty obvious that they match the underlying Selenium version. I'll switch our CI over to version 3.14.0-p17 and give you an update with the results 🚀

@adamjson
Copy link

adamjson commented Feb 11, 2019

I had a quick read through this ticket and it does in fact seem like our issue described by 6918 is probably the root cause of this issue. We injected a quick patch into our grid and the problem went away. The "proper" fix was a bit more involved and a PR was just submitted for review.

It also worth mentioning that when we had throwOnCapabilityNotPresent set to true, we saw the "Empty pool of VM for setup ..." error message. After flipping that flag to false, everything hung up because the nodes would never finish registering and the hub would just hang onto the new session requests indefinitely.

@elgalu
Copy link
Owner

elgalu commented Feb 11, 2019

SeleniumHQ/selenium#6918
SeleniumHQ/selenium#6924

@andrejska
Copy link

@diemol I am quite sure that it started with 3.141.59, right now I am using 3.14.0 running thousands of jobs per day without this issue

What is your plan to deal with this until Selenium hasn't fixed these issues as latest docker-selenium release are not usable and we are quite behind latest Chrome version :(

elgalu added a commit that referenced this issue Feb 16, 2019
elgalu added a commit that referenced this issue Feb 16, 2019
@elgalu
Copy link
Owner

elgalu commented Feb 16, 2019

all: thank you so much for nailing this down!

Rolled back to the last working version via #305 36f32a6

For now, until Selenium fixes upstream.

Latest release now has latest Chrome, latest Firefox, last working Selenium version:
https://github.com/elgalu/docker-selenium/releases/tag/3.14.0-p19

zammad-sync pushed a commit to zammad/zammad that referenced this issue Mar 7, 2019
diemol added a commit that referenced this issue May 1, 2019
* Using self built jar.

* Ignoring IntelliJ directory

* Updating Chrome version
@diemol
Copy link
Collaborator

diemol commented May 1, 2019

Closed via #319

@diemol diemol closed this as completed May 1, 2019
@diemol
Copy link
Collaborator

diemol commented May 1, 2019

Reopening, wasn't really included in the release 🤦‍♂

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants