Key: |
QB-722
|
Type: |
Improvement
|
Status: |
Resolved
|
Resolution: |
Fixed
|
Priority: |
Major
|
Assignee: |
Robin Shen
|
Reporter: |
Robin Shen
|
Votes: |
2
|
Watchers: |
0
|
If you were logged in you would be able to see more operations.
|
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
From customer,
Without a lot of history, here is what appears to cause a problem. We have many dependent builds. Most of these builds are set to run mode of DISABLED as they are triggered in groups through dependency checking.
Due to a misconfiguration, several of these tiggering builds were set to run mode CONCURRENT. All of our builds assume an isolated workspace, and so CONCURRENT is clearly wrong.
However, it appears that this run mode is being "inherited" by the DISABLED builds when they are triggered from a CONCURRENT build. Before we changed the triggering builds to SEQUENTIAL we noticed all of our builds running CONCURRENT.
It seems that since the concurrent build capability of a build should apply even when DISABLED, that it should be its own property.
|
Description
|
From customer,
Without a lot of history, here is what appears to cause a problem. We have many dependent builds. Most of these builds are set to run mode of DISABLED as they are triggered in groups through dependency checking.
Due to a misconfiguration, several of these tiggering builds were set to run mode CONCURRENT. All of our builds assume an isolated workspace, and so CONCURRENT is clearly wrong.
However, it appears that this run mode is being "inherited" by the DISABLED builds when they are triggered from a CONCURRENT build. Before we changed the triggering builds to SEQUENTIAL we noticed all of our builds running CONCURRENT.
It seems that since the concurrent build capability of a build should apply even when DISABLED, that it should be its own property. |
Show » |
|