[🚀 Feature]: Cache Selenium Manager #11359
Comments
|
Worth mentioning that Java is doing it like that because the binary is inside a jar. |
|
We're packaging the binaries in all the bindings, some languages just make it easier to get them than others. |
|
If the selenium-manager binary path contains its version, step 2 is not necessary. Also, the arch is not required in the path, since the binary is unique for the underlying platform. For instance:
|
|
How is it more unique than the drivers? |
|
I see it as an idea to avoid calling the binary and asking the question. Sounds like a good approach to me. |
I consider it different things. For me, Selenium Manager is a tool that manages drivers, which means, in short, that it downloads drivers automatically. But Selenium Manager does not know the user's intentions regarding the downloaded driver. Maybe they will be executed on the local machine, or perhaps they are intended for other uses (e.g., hosted and served on a server). In any case, Selenium Manager should be able to download drivers even for a different platform that the local host. Regarding the |
|
Is the feature you are suggesting for supporting alternate architecture drivers on the road map? |
Not explicitly, but I consider it as part for the advance configuration (M3). Before starting that milestone, I will propose something more specific, such as the parameters to be tuned (e.g., TTL, OS, architecture, proxy, etc.) or the use of envs for these values (which can be interesting, IMO). |
|
The bindings should be aware of the Selenium Manager version they are shipping. For instance, Selenium
It is a cache folder, so IMO it is not big deal to store also old versions of Selenium Manager (it also happens with the drivers).
I think so, having a Selenium Manager binary in the cache folder allows to play with it. |
|
Aha, I see what you're suggesting now. That works. Thanks. |
|
This was discussed at the TLC Meeting - https://www.selenium.dev/meetings/2022/tlc-12-08/#proposalsdecisions It was agreed that there was no good reason not to do this, but also as a minor optimization it might not be worth doing. I'll end up implementing it if I get too frustrated working with .NET :) |
|
Based on some of the difficulties we are facing in troubleshooting problems, I think this issue might be more important. If someone has a problem it would be nice to tell them to directly run: This would be an issue of bindings saving the binary there and checking the versions. We'd need to also agree on the versioning scheme. |
|
As discussed on Slack, the preferred schema for the Selenium Manager versioning will follow the same version as Selenium, starting with In my opinion, this issue (to extract/copy the Selenium Manager binary to the cache folder by the bindings) is quite relevant since it will allow users to play with Selenium Manager if needed. For instance, the troubleshooting procedure will be more effortless. Therefore, it would be great if this could be implemented for Selenium 4.12.0. |
|
Does this mean we will upload the Selenium Manager binary to the 4.12.0 release or we will create a 0.4.12 tag and release separately? |
|
As I see it, this issue differs from releasing Selenium Manager as an independent artifact. To implement it, first, we need to agree on a versioning schema for the upcoming versions of Selenium Manager. Let's suppose the next SM version is 0.4.12. Second, I change that version on the Rust side, which is straightforward. Third, the bindings should know that the SM binaries they are shipping is that version (0.4.12). With that info, they look for this release on the cache in a known path, like |
|
It's not applicable for .Net - binary is copied to users' known output at build phase, not at runtime. This way allows us guarantee a compatibility between C# code and selenium-manager. |
|
@nvborisenko Can we put the logic for storing it in |
|
I strongly disagree. I have
Each version of Selenium.WebDriver comes with own version of selenium-manager. I see conflicts when each project will write something to shared location. NuGet package is not something global, it's per user/project/process/whatever. By the way what issue in .Net we are trying to resolve? |
|
Right the plan is to put them like: There are a number of use cases for this. One is that if someone needs to build their own Selenium Manager, they can put it in the applicable directory and override the default one. And generally we'd like it to be in the same place for all the bindings for consistency. |
|
So we agreed that Selenium Manager Manager is not a good idea. As @nvborisenko suggested, we could use an environment variable to specify the location of a custom version of selenium manager if someone needed to put it in a place they had permission, or someone wants to test a custom version, or someone wants to build one for their architecture and use it to find special drivers on PATH... Java not having to copy the file to a temp directory every time it gets used seems like a Java issue that Java can sort out for itself? Is putting it in |
…12539) * [java] Copy SM binary to cache folder and use it from there * [java] Read cache path from the config file and as env * [java] Read cache-path as env only * [java] Use BuildInfo class to get current Selenium version * [java] if cache path is not writable, SM will be extracted to a temporal folder * [java] Include shutdown hook again to delete binary when stored in tmp folder
…HQ#11359) (SeleniumHQ#12539) * [java] Copy SM binary to cache folder and use it from there * [java] Read cache path from the config file and as env * [java] Read cache-path as env only * [java] Use BuildInfo class to get current Selenium version * [java] if cache path is not writable, SM will be extracted to a temporal folder * [java] Include shutdown hook again to delete binary when stored in tmp folder
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Status
For now, we're only doing this in Java, because Java is the only one that requires streaming it for each process.
Fixed by #12539
Feature and motivation
Right now, Java is decompressing the binary and putting it in a temp file, and all the other bindings are using them directly from where they are stored from within the respective package.
One option is to have the bindings as part of
getBinary():~/.cache/selenium/selenium-manager/mac64/selenium-manager)The advantages are:
Usage example
n/a
The text was updated successfully, but these errors were encountered: