A configuration suggestion could be to have different configuration type, defaulting to "inherit from master"

• Inherit from master (takes the config from the global jenkins manage configurations)
• From config file
  • Specify config file (yaml or xml with detection of config type so the selenium proces starts with the right flag)
• Manual flags configuration
  • Same fields as the current global configuration in jenkins "manage" page

Richard,

Here are a few things that I would want to be able to do using the plug-in.

a. Customize the hub by passing in a configuration file (a yaml file so that the grid works parsing it Selenium1 grid mode), or a JSON file (Selenium2 grid mode)

b. Customize the node by passing in either a JSON configuration file (or) by passing command line arguments as well.

c. A provision to specify the chromedriver binary where it exists, because when a webdriver node is spawned, unless and until it is fed the chromedriver binary path, chrome executions may not work.

d. The grid has the capability to accept servlets which can be injected into it. So I would want a provision wherein I can provide a custom built jar that can be accepted by the plug-in, added to the classpath and then it be injected into the grid via the -servlets command arg.

e. The node has the capability to accept custom proxies (apart from the default proxy). I would want a provision wherein I can provide this as well.

f. Currently the plug-in works on by depending on a specific version of the selenium standalone jar. If there is a way to de-couple this plug-in and the jar it works with, it would give me the flexibility of upgrading the selenium2 dependency based on the selenium release and not warrant an updating of the plug-in.

I am pretty new to jenkins plug-in development and I have no clue as to how things work in general. If you have some time to walk me through on some basics, perhaps I can pitch in on this as well.

Thanks for the feedback.

Here is some precision about how these needs.

Since I don't want to clutter the configuration UI, some configurations will only be available through the FileConfiguration, I'm talking about d and e here. This is some pretty advanced config which I doubt will be frequently used in jenkins.

A, B and C are going to be taken care of (b is done, a was not in my mind but easy to do, and e only needs to specify the path for chromedriver which is easy as well)

F is behing handled by another issue, see https://issues.jenkins-ci.org/browse/JENKINS-12675

If you want to check the code I've done so far, you can take it from : https://github.com/darkrift/selenium-plugin

I'm fairly new to jenkins dev as well, started doing those changes 2 weeks ago but it's rather easy once you know the available parts in jenkins.

If you have anything else you want, please submit them.

Richard

Can you just explain the goal of D ?

Since the hub is running in jenkins directly, I don't see how this could be useful for one to specify it's servlets. Thinking about it, I even doubt it will work to add the custom jar to allow that just like you don't have the flexibility to specify your own CapabilityMatcher because it's jenkins that handles that ...

Maybe that needs to be thought about, but I don't see the use rather than using an independant grid for more complex configurations/specifications.

What's your thoughts about it ?
Thanks
Richard

Richard,

The goal of D would be to provide customization to the Grid.
Here are some scenarios wherein this will be useful.

a. I have a servlet that I have integrated with VNC, which provides me a way using which I can let my end users watch their automation on the actual remote machine.

b. I have a servlet which restricts nodes from registering themselves to my grid. Only nodes whose IP addresses are known to me would be allowed to register themselves with me.

c. I have a servlet that keeps track of how many tests were run on a particular node, before deciding to clean it up.

But yes, I agree completely with you. These are pretty complex configurations/specifications which not everyone would want to use. As such these are "Nice to have" features but not something that needs to be absolutely present in the plug-in.
So I think we can live with the fact that the Jenkins selenium plugin wouldnt provide for such features.

So for now D and E can be skipped and even then this plug-in would be an awesome way for end-users to make use of.

Btw, the following things came up to my mind when you asked me if I had any additional reqs.

Would jenkins inherently let me do the following ?

1. The grid (spawned by the selenium plug-in) hung and needs to be restarted. How do I accomplish that ?
2. One or more nodes (slaves in this case) got hung and needs to be restarted. How do I accomplish that ?

Pardon me for not paying attention to this thread. I was under the assumption that whenever any new comments got added, it would automatically trigger an email, which wasn't the case here
I will be more vigilant going forward.

And yes, I do want to take a look at your delivery, just to atleast get a feel of how jenkins development works in general and if possible provide some small contributions as well.

~Krishnan

Hi Richard,

When can we expect this change would be done and updated to the plugin. I could do this through Selenium Grid now but waiting to configure my scripts to Jenkins

Or please provide some information if we have any workaround to start a user specified configuration for a slave

Thanks,
Bala

The latest version of the plugin (v2.1) now allows configurations for slaves with multiple running configurations per node as well.

They can also be started/stopped and restarted by the management page.