| Key: |
QB-915
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Won't Fix
|
| Priority: |
Major
|
| Assignee: |
Robin Shen
|
| Reporter: |
Don Ross
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 20/May/11 02:05 PM
Updated: 26/May/11 11:38 PM
|
|
| Component/s: |
None
|
| Affects Version/s: |
3.1.38
|
| Fix Version/s: |
None
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
Environment:
|
Centos5 server; Windows 2008 or Windows 2003 agents
|
|
|
I have a farm consisting of twelve agents; six Windows 2008 amd64, and six Windows 2003 x86.
These are further subdivided into agents running in two different Windows domains (englab.qa and englab.local).
My node selection criteria is 'matching all specified criteria'
- on Windows node
- on any build agent
- script evaluating to true:
groovy: node.getAttribute("PROCESSOR_ARCHITECTURE").compareToIgnoreCase(vars.getValue("param_serverBitness")) == 0
- script evaluating to true:
groovy: node.getAttribute("USERDNSDOMAIN").compareToIgnoreCase(vars.getValue("param_serverDomain")) == 0
The requestor is then able to specify values for param_serverBitness and param_serverDomain from drop-down lists.
I also have a semaphore lock to prevent multiple jobs running on the same system at the same time:
groovy: node.getResource("SingleThread", new java.util.concurrent.Semaphore(1)).acquire();
groovy: node.getResource("SingleThread").release();
I have found that, if I trigger four jobs all with the same values for param_serverBitness and param_serverDomain, the first three run on the nodes which satisfy those criteria. The fourth job runs on a randome node with the correct USERDNSDOMAIN, but the wrong PROCESSOR_ARCHITECTURE.
|
|
Description
|
I have a farm consisting of twelve agents; six Windows 2008 amd64, and six Windows 2003 x86.
These are further subdivided into agents running in two different Windows domains (englab.qa and englab.local).
My node selection criteria is 'matching all specified criteria'
- on Windows node
- on any build agent
- script evaluating to true:
groovy: node.getAttribute("PROCESSOR_ARCHITECTURE").compareToIgnoreCase(vars.getValue("param_serverBitness")) == 0
- script evaluating to true:
groovy: node.getAttribute("USERDNSDOMAIN").compareToIgnoreCase(vars.getValue("param_serverDomain")) == 0
The requestor is then able to specify values for param_serverBitness and param_serverDomain from drop-down lists.
I also have a semaphore lock to prevent multiple jobs running on the same system at the same time:
groovy: node.getResource("SingleThread", new java.util.concurrent.Semaphore(1)).acquire();
groovy: node.getResource("SingleThread").release();
I have found that, if I trigger four jobs all with the same values for param_serverBitness and param_serverDomain, the first three run on the nodes which satisfy those criteria. The fourth job runs on a randome node with the correct USERDNSDOMAIN, but the wrong PROCESSOR_ARCHITECTURE.
|
Show » |
|
when appropriate node is not available, job runs on inappropriate node
groovy: node.getAttribute("COMPUTERNAME").compareToIgnoreCase(vars.getValue("param_runHostName").tokenize('.')[0]) == 0
and it was not reproducible. So it may be because I have multiple criteria.