Closed SiKing closed 5 years ago
If you log onto the Jenkins build agent is it able to see:
https://chromedriver.storage.googleapis.com/2.31/chromedriver_linux64.zip
I do not have terminal access to the Jenkins machine - checking with my admin. However, if it were not able to see it, wouldn't throwExceptionIfSpecifiedVersionIsNotFound
in the pom kick in?
The error being thrown is here:
That's the exception thrown when a download fails.
Looking at this implies something else has accessed the file while the plugin is trying to download it:
https://stackoverflow.com/questions/16764946/what-generates-the-text-file-busy-message-in-unix
Is it possible the plugin is still accessing it? Decompressing it, checking the hash, ... Also, what exactly is "it" in this case?
Without the RepoMap I do not see this error.
The plugin is single threaded, it will not error if it is accessing the file itself. The it referred to above is the file the plugin has downloaded.
If you run two instances of the plugin at the same time and they are both downloading files to the same location you may see this, but then that's would be a bigger problem because your Jenkins builds would be sharing the folder structure during builds (which would be bad).
If you don't supply a repomap the plugin will use a default one, that implies that the file location you have entered in your repomap is wrong, but that doesn't match the error thrown by the stack trace.
Got word back from our admin: he can download chromedriver_linux64.zip from Jenkins just fine.
I was able to spend some more time on this today.
First thing I discovered is that customRepositoryMap
must contain the full path; you can use something like <customRepositoryMap>${project.basedir}/RepositoryMap.xml</customRepositoryMap>
. If you do not have a full path (only something like <customRepositoryMap>RepositoryMap.xml</customRepositoryMap>
), the plugin will check the supplied file for existence and validity, but then ignore it and use the internal map!
Second thing I was able to determine, is that if the extracted driver binary already exists (so in my case selenium/bin/linux/googlechrome/64bit/chromedriver
) somebody is doing something with it, causing the "Text file busy" error.
I ran the build with -X, and the plugin got as far as "[INFO] Extracting binary 'chromedriver'..." I am not sure if the "somebody" is Jenkins or the plugin, and I definitely have no idea what the "something" could be. I cannot reproduce this when run on a local machine without Jenkins.
In my project I enabled "clean workspace" and this error went away. The unfortunate thing is that the driver binaries have to be downloaded for each build.
The above implies that your workspace is being shared between jobs and another job is using the workspace when you are trying to extract chromedriver from the jar.
I'll have a look and see if I can reproduce this.
I got bit by this today, again. Spent some time researching this issue.
The root of the problem was that on Jenkins we still had hanging threads running chromedriver from previous cancelled jobs. If I fist ran pkill -9 chromedriver
before my job, then everything worked as expected.
I feel like this is not a problem with the binary-downloader plugin, but more of a problem with chromedriver.
I would concur :)
Running on Linux. First time using RepositoryMap.
pom.xml has:
RepositoryMap has:
From Jenkins I get an error: