Florianrein's Blog

Kategorie: CI

Posts about Continuous Integration

  • Problem reading geckodriver versions: error sending request for url

    Today, while hunting down a nasty issue in a longer Selenium/Cukes scenario outline, I was flooded with a particular annoying warning:

    WARNING:
    org.openqa.selenium.manager.SeleniumManagerlambda$runCommand$1
    Problem reading geckodriver versions: error sending request for
    url (https://raw.githubusercontent.com/SeleniumHQ/selenium/trunk/common/geckodriver/geckodriversupport.json).
    Using latest geckodriver version

    org.openga.selenium.manager.SeleniumManagerlambda$runCommand$1
    WARNING: Exception managing firefox: error sending request for
    url (https://github.com/mozilla/geckodriver/releases/latest)

    You too? Then you are at the right place.

    The reason

    Selenium is trying to check for an update for your geckodriver executable. What is planned as a nice convenience feature can be quite an annoyance in a restricted environment. When Selenium is executed within such an environment, it cannot contact the remote geckodriver version dictionary and nags us with „Problem reading geckodriver versions: error sending request for url …“.

    Thankfully the Selenium team seems to be aware of that and provided us with a simple fix. Sadly that fix is quite non-explicit but that’s not going to stop us anytime soon.

    Fixing the „Problem reading geckodriver versions: error sending request for url“ warning

    The update check happens if – and only if – Selenium derives the geckodriver path from Seleniums automatic lookup feature (i.e. when it checks the system PATH variable). Therefore all we have to do is setting the geckodriver path explicitly. In Java we do that like this:

    System.setProperty(“webdriver.gecko.driver”, “/path/to/your/geckodriver”);

    By setting that Java system property we tell Selenium explicitly what geckodriver to use and we prevent it from doing any additional shenanigans on the driver binary thus silencing the warning. Using an appropriate if-clause you can tailor it to any kind of environment. You have full internet access? Cool! Then your system geckodriver might be perfectly sufficient. It’s all in your hands.

    Final thoughts

    Alright! This should relieve you from that „Problem reading geckodriver versions: error sending request for url“ warning. When working with complex Selenium Webdriver tests, it is overall nice that the framework logs so verbose and provides us with all these features. But sometimes it can be a little full of itself. The good thing is though that there usually is a way to customise Selenium’s behavior to our personal needs, whether it is working in a restricted network area or with full access to the internet – Selenium knows it all.

    Though sometimes it has its difficulties to articulate itself – just as we humans do. Anyways, thank you for reading. If you are still curious about what’s possible with Java in QA, here’s an interesting post about fuzzing in Java. If you don’t particularly care about Java but you would like to see more test automation action in general, I’d recommend trying Cucumber in Rust.

    Have a great day!

    Share it with:

  • Gitlab CI Error – Cannot create local repository at: /.m2/repository

    When you are using downstream pipelines in Gitlab CI for complex Maven Projects as I do, you may have stumbled accross this error at least once: Cannot create local repository at: /.m2/repository. The Gitlab runner tries to create a local Maven repository at /.m2/repository – so in the topmost directory – and fails horribly due to an obvious lack of permissions. Let‘ see what happens here.

    The Gitlab CI Setup

    In my case I had a shell-based Gitlab runner that executes a test suite based on a few artifacts published by a Docker runner. Due to versioning and system test level realism reasons I was not able to use the artifacts directly. Unfortunate, but it shouldn’t pose that kind of a problem, does it?

    Now when it comes to cloning the test suite on my shell runner, this cryptic error has been dropped. And naturally I was like „WTF is this runner trying to do!?“

    The root cause in Gitlab CI downstream jobs

    What I was not aware of is that per default the „child job“ inherits all the custom and Gitlab-provided runner variables from the triggering parent job that is still executed on a Docker runner. Now since the trigger happens from a Docker runner job, the variables my child job receives are poison for a baremetal environment that is my shell runner. Not least because things actually do happen at / in a Docker-based Gitlab execution environment, which is perfectly fine, but not on a shell runner.

    The solution: What I had to do to make the CI jobs work

    To fix the problem I had to set this on my trigger job definition:

    inherit:
  variables: false

    This did not just fix the error for me, but it also made perfect sense. Due to the different execution environments – shell vs. docker and project A vs. project B – I have a different set of requirements for my Gitlab CI test job. Therefore we have another case of an error leading to better software design. In addition I learned another piece of Gitlab’s sometimes quite obscure default settings.

    Conclusion

    I hope this helps you during your day to day journey through the jungle that are Gitlab CI downstream jobs. As I’m an avid QA engineer, so if you want to read more about writing actual automated tests. Also I take care of deeper coding basics like working with threads in java. If you’d rather want to read up about Gitlab CI’s inherit keyword, here’s the link to the relevant section of the official Gitlab CI documentation. Feel free to have a look!

    Have a great weekend everybody!

    Share it with: