testomat.io управление авто тестамиОн хочет скачать геккодрайвер для фаерфокса.
Вы можете сами скачать нужную для вас версию Releases · mozilla/geckodriver · GitHub и положить в папку с проектом.
2 лайка
Не совсем понятно, куда я должен его положить, в resources?
Рядом с помником - автоматом будет подтягиваться.
Либо куда хотите (ресурсы и т.п.) - нужно сетить системную переменную webdriver.gecko.driver с путём до драйвера - Usage — Firefox Source Docs documentation
1 лайк
То что вам советуют положить рядом бинарник - это костыль, который потом надо будет исправлять рано или поздно.
Ваша ошибка говорит о том, что у вас, скорее всего, нет доступа к гитхабу с этой машины.
На вашем месте я бы решал проблему (открывал доступ для скачивания драйвера), а не её последствия.
У меня нет возможностей открывать доступ к внешним сервисам, все машины находятся за прокси. + на билд сервере, который вообще находится во внутренней сети, никаким образом не откроют доступ во внешнюю сеть.
Интересная политика - билд-сервер и без доступа во внешнюю сеть…
Как же вы зависимости тянете? Костылями типа своего нексуса? 
По-моему как раз-таки билд сервер и должен иметь выход во внешнюю сеть. А собираться всё должно вообще в контейнерах докера, например.
После чего уже артефакты сборки кочуют туда, куда им следует…
Так что следует посмотреть в сторону налаживания инфраструктуры - начальству написать, например, что всё через одно место организовано и это мешает процессу тестирования в том числе.
Никто не мешает сис. админами выдать доступ к конкретным сайтам конкретным машинам.
А вот городить костыли можно всегда успеть. Попробуйте решить проблему правильным путём - объяснением людям, отвечающим за выдачу доступа во внешнюю сеть, что это необходимо.
Вполне нормальная история, когда билд-сервер и без интеренета нормального
Работал одно время в банке одном. Там служба безопасности имело очень много влияния. И вот если безопасники сказали “никакого интернета”, то сисадмины ничем не помогут
И крутитесь как хотите
Да, не везде департаменты работают слаженно для общей цели.
Так что ситуацию автора вполне понять можно
По поводу проблемы
If you use another webdriver (or a custom WebDriverProvider ), WebDriverManager will not be used, and you will continue working as previously.
Вопрос теперь в том, чтобы скормить ему кастом провайдер и тогда не будет пытаться скачать
Call method
WebDriverRunner.setWebDriver(WebDriver)explicitly
2 лайка
Никакие кастомные провайдеры не нужны. Положите драйвер в папку с проектом и в setUp() методе засетайте пропертю System.setProperty("webdriver.gecko.driver", "Path to driver" и все.
2 лайка
именно так
по- моему такая ситуация во всех больших конторах, запретить все, что можно. Программировать через RDP на виртуалках в защищенной сети. А тут про билд сервер говорят с выходом в интернет. 
Это политика банков, где СБ не блокирует, а разрешает что-то из всего заблокированного
В нормальных компаниях люди понимающие, что доступ к таким вещам как гитхаб должен быть открыт
Правильный ответ прозвучал выше:
Никакие кастомные провайдеры не нужны. Положите драйвер в папку с проектом и в setUp() методе засетайте пропертю
System.setProperty("webdriver.gecko.driver", "Path to driver"и все.
И ещё правильный вопрос прозвучал. @All_Safe хотелось бы услышать ваш ответ: как же вы остальные зависимости подтягиваете без доступа к интернету - тот же самый selenide-4.9.1.jar?
1 лайк
@asolntsev расскажите пожалуйста как правильно локальный artifactory собрать все - особенно со злым жадным springboot проектом. - чтоб не требовался выход в паблик итнернет.
кстати таж проблема но сбоку - с gem
Ну так это вопрос к вашей службе безопасности. Они ставят нелепые требования. Ну установите вы свой локальный artifactory. И что они, будут вручную проверять все джарники и XML, которые вы попросите туда положить?
По-любому кто-то должен закидывать в artifactory нужные зависимости, и ему по-любому нужен для этого выход в интернет.
Artifactory обычно используют, чтобы
- кэшировать зависимости из центрального мавеновского репозитория (вдруг они оттуда пропадут)
- Складывать туда свои джарники, которые хочется переиспользовать между проектами.
я хотел услышать ваше авторитетное мнение как предотвратить скажем меняеш minor version у одной из зависимостей и как спастись он новой кучи прилетающего хлама…
померять просто:
find ~/.m2/repository/ -type d |wc
и видишь позорные груды
5808 5808 407168
(и это несмотря на периодический purge)
уберечься сложно
кстати я не полностью уверен что соглашусь c утверждением что требования службы безопастности нелепые.
через nexus, поднятый внутри корп. сети
И как это улучшает безопасность?
А что же в этом позорного? Ну вот сформулируйте конкретно, в чём проблема. Мне кажется, вы беспокоитесь не о том, о чём надо беспокоиться.
Естественно, я имею в виду не вообще все требования, а конкретно это: запретить выход в интернет с билд-сервера.
Б! Безопасность!
Я лично предполагаю, что возможно условным “Касперским” jar-ники проверяют
Сам работаю в подобной конторе, поэтому, когда нужно заюзать новую либу, то “молюсь”, чтоб в локальной копии публичного мавена оказалась не совсем протухшая зависимость.
прямо рядом похожая тема обсуждается — Подключение Lombok к проекту java + exec-maven-plugin - #15 от пользователя ramonmenezes