[🚀 Feature]: Cache Selenium Manager

[titusfortner]

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():

1. check to see if the manager exists at a designated location (~/.cache/selenium/selenium-manager/mac64/selenium-manager)
2. If it is get the version
3. Compare the version to the "latest" (to start with we should keep this a constant with the selenium version being used)
4. If it is the latest, use it, if it isn't decompress/stream/move from package to the cache location

The advantages are:

1. No copying to temp files
2. It would be the first step for Selenium Manager Manager ([🚀 Feature]: Selenium Manager Manager #11358) if we went that route
3. I can just copy test binaries into the system directory to test them instead of needing to go through bazel (hard in some language, and actually impossible in .NET right now)

Usage example

n/a

[diemol]

Worth mentioning that Java is doing it like that because the binary is inside a jar.

[titusfortner]

We're packaging the binaries in all the bindings, some languages just make it easier to get them than others.

[bonigarcia]

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:

~/.cache/selenium/manager/1.0.0/selenium-manager

[titusfortner]

How is it more unique than the drivers?
Seems they should be treated the same, either way?

[diemol]

I see it as an idea to avoid calling the binary and asking the question. Sounds like a good approach to me.

[bonigarcia]

How is it more unique than the drivers?
Seems they should be treated the same, either way?

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 selenium-manager binary, it is placed in that path by the binding, with the intention of running it. So there is only a possible binary, at least at this moment.

[titusfortner]

Is the feature you are suggesting for supporting alternate architecture drivers on the road map?

[bonigarcia]

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).

[titusfortner]

If the selenium-manager binary path contains its version, step 2 is not necessary

1. How do the bindings know what path it's in? Iterating directories is easier in some languages than others.
2. Unnecessary to have this as there's no reason to have more than one version at a time.
3. Pretty much being able to copy/paste *any version of the manager to one place and use it for dev purposes is my primary use case right now.

[bonigarcia]

• How do the bindings know what path it's in? Iterating directories is easier in some languages than others.

The bindings should be aware of the Selenium Manager version they are shipping. For instance, Selenium 4.6.0 was shipped with Selenium Manager 1.0.0-M1'. This way, each binding should know that version (using a constant in the code is the simplest way). The inconvenient of this approach is that we need to remember to bump this number in the bindings before a release is done. The advantage is that the location of the Selenium Manager binary is straightforward.

• Unnecessary to have this as there's no reason to have more than one version at a time.

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).

• Pretty much being able to copy/paste *any version of the manager to one place and use it for dev purposes is my primary use case right now.

I think so, having a Selenium Manager binary in the cache folder allows to play with it.

[titusfortner]

Aha, I see what you're suggesting now. That works. Thanks.