Your browser was unable to load all of the resources. They may have been blocked by your firewall, proxy or browser configuration.
Press Ctrl+F5 or Ctrl+Shift+R to have your browser try again.

Pool of named resources #4321

pendor ·

I have a build which runs automated application testing on multiple QB agents. We have a pool of user accounts in the application (TestUser[0..14]), each of which has a set of sample data populated. It's important that only a single test suite is running for each TestUser at any time, otherwise they step on each others' data and some tests will fail.

Currently we have 15 physical Windows machines running the QB agent. We're trying to move those to dynamically spawned Azure VM's that QB can create & destroy. The physical machines all have an "id" set as a node property which assigns them to one of the 15 user accounts. That (rather clunky) approach won't work with agent nodes that are spawned & destroyed on command.

My initial thought is I want something like Resources, but simply tracking how many resources are available isn't sufficient. I need a collection of named items, one per TestUserX account. Each item should be assigned exclusively to a spawned VM for the duration of the build.

I'm guessing something with pre-post execute scripts might keep a record of accounts in use & assign them per build. Is there any established way to do something like this that I'm missing?

Thanks in advance,

  • replies 3
  • views 113
  • stars 0
robinshen ADMIN ·

You may define 14 cloud profiles. These cloud profiles share the same Azure image, but specify different "id" user attributes in profile definition. Also make sure to configure "max nodes to launch" as 1. Then in resource definition, define a resource to match all these cloud profiles.

pendor ·

I hadn't even considered it from that direction. That makes a lot of sense and also means little or no modification to our existing configuration.

I'm guessing if each of those profiles provides one of our testing platform resource, the node selection / cloud spawning logic should spin up as many individual profiles as necessary to satisfy any parallel blocks in the build and/or until it runs out of distinct agents, right?

I may take a look at the REST API to see if I can define those programatically based on a max count rather than creating them by hand.

Thank you!

robinshen ADMIN ·

Yes that is correct.