I have a project that has multiple steps that run selenium tests.
Currently, we have one deployment target that runs the tests for all test steps. This can cause a bottleneck when we have multiple environments deploy the same project.
I would like to set up another deployment target, then add that deployment target as an additional option for each of those steps.
I think if I do this, the step will just run on both environments. Instead, is it possible to treat these deployment targets as a pool and deploy only to the first available target?
Greetings Tyson! Do you know if it’s possible to have those Selenium tests run on a worker instead of a target? If so, you could utilize a worker pool for such a purpose.
If you’re on a legacy license, using Workers won’t be a viable option. If you’re on a newer license, it should tell you how many workers you can have. Workers are tentacles, but they’re not targets and don’t count against your aggregate total. (https://octopus.com/docs/infrastructure/workers). Workers can be placed in a pool so when a deployment step that needs one, it checks it out from the pool to do the task, then it gets put back into the pool. For your purpose, it sounds like that is what you’re looking for.
One thing to be aware of is that Workers don’t have things deployed to them, however, it is possible to reference a package and have the worker extract the package and do something with the files. See blog post https://octopus.com/blog/worker-friendly-step-template
After setting up a worker, running into a license limitation, then actually reading the Worker/Worker Pool documentation, I’m starting to wonder if this approach will work for me.
The main issue I see is that Workers can run multiple tasks simultaneously. For my situation, that is a problem. I am wanting to use a Worker to run a script on a Test Controller VM that triggers a test run. I want the Worker Pool to choose a Test Controller that is not currently running tests. I don’t know if that is possible.
We currently run tests using the Test Controller VMs as a Deployment Target. This ensures only one deploy uses one Test Controller at a time but creates a bottleneck. Another option is to have more controllers and use different controllers on different steps. That can work, but Workers seems like it could be so much more efficient.
Here’s something like the scenario I am dealing with:
Let’s say I have two workers, each is a Visual Studio Test Controller.
These two workers are in a pool (not the default pool).
I have a project that has a step that unpacks a nuget package and calls a powershell script, using the pool.
The project lifecycle has 10 environments.
Two deployments get triggered for two different environments, roughly at the same time
Deploy 1 gets to the test step. Worker 1 is chosen from the pool.
Deploy 2 gets to the test step.
a. What I want to happen here is for Worker 2 to be chosen from the pool.
b. What I think will happen is that Worker 1 maybe be chosen again, running the script against the same Test Controller as Deploy 1. This doesn’t really help me much.
Let me know if any of that does not make sense.
Am I thinking correctly, that Workers aren’t going to solve my issue? Is there something I’m missing?
Hello there Tyson! When a worker is doing a task, it is checked out of the pool. As long as the task is executing, the worker remains checked out until the task is completed. In your scenario, if the tests are still underway, the worker would remain checked out from the pool and the second execution would be picked up by another worker in the pool, if available. Does that make sense?
Hey there Tyson! You are correct, I was mistaken. By default, the worker can execute multiple things at once. You are able to change that so that it is a blocking task by altering the mutex property. This article, https://octopus.com/docs/administration/managing-infrastructure/run-multiple-processes-on-a-tentacle-simultaneously, shows how you can configure a tentacle to execute multiple things at once. In your scenario, you’d do the opposite and set the value to False so that the worker will be exclusive.
Hi Tyson! For a deployment target, yes, it is defaulted to false. For Workers, it’s defaulted to true, so you’d still have to explicitly set it to false.
