huserben / TfsExtensions

Extensions for TFS 2015+ such as custom Widgets (require TFS 2017) and Build Tasks
MIT License
44 stars 22 forks source link

Demands appear broken #250

Open Erich-McMillan opened 8 months ago

Erich-McMillan commented 8 months ago

In Release pipeline (GUI view) attempted the following:

image

But agent was scheduled on a system with unmatched demand value.

Debug output from task:

2023-10-30T23:30:10.6120595Z Using following Authentication Method: Personal Access Token
2023-10-30T23:30:10.6121096Z Using Personal Access Token
2023-10-30T23:30:11.6052507Z Provided team project was guid.
2023-10-30T23:30:11.6053172Z Context is Release - using Release Environment Variables
2023-10-30T23:30:11.6054158Z Build shall be triggered for same user that triggered current Release: Erich McMillan
2023-10-30T23:30:11.6054816Z Will trigger build with following demands:
2023-10-30T23:30:11.6055170Z HIVE_ES_DUT_CHIPSET -equals 8280

Thoughts on how best to determine why this occurs?

huserben commented 8 months ago

Hi @Erich-McMillan

interesting, it seems like the demand was properly parsed and thus I would assume it's been properly sent to the API. Was it ever working and suddenly started to fail? Or is this not working since the beginning?

What is puzzling me a bit is that according to my own documentation, it should fail if it doesn't find an agent with the demand:

"Note: If no suitable agent is available with the specified demands, the build cannot be triggered and the Task will fail!"

Could you provide the other settings you use for the task? I would assume you specify an Agent Pool to use. Another you could try, can you specify a "random" demand that doesn't exist and see if the task then fails? That might help with further debugging.

Thank you!

Erich-McMillan commented 7 months ago

@huserben

Hadn't used it before in the past, so I assume it may just be broken.

I attempted to queue the build directly using https://learn.microsoft.com/en-us/rest/api/azure/devops/build/builds/queue?view=azure-devops-rest-7.0. I believe the demands request is completely ignored as I was unable to find any format where it was respected. Even with a completely random demand the job continued as expected.

The other potential reason could be that the pipeline itself specifies both Pool:\n name: and Pool:\n demands:. Perhaps when these exist in the yaml the API inputs are ignored, though I haven't seen this documented anywhere?

I'll open a bug ADO and link it here.

Erich-McMillan commented 7 months ago

Here's the api call body I used:

{ 
  "definition":
  {
    "id" : 295
  },
  "requestedFor" :
  {
    "id" : "$(Release.Deployment.RequestedForId)"
  },
  "requestedBy" :
  {
    "id" : "$(Release.Deployment.RequestedForId)"
  },
  "sourceBranch" : "prerelease/3",
  "retainedByRelease" : true,
  "demands" : [
    "RANDOM_DEMAND",
    "HIVE_ES_DUT_CHIPSET -eq 8280"
  ],
  "templateParameters": {
     "workingDirectory" : "$(engineeringSystemDirectory)",
     "robotTestPaths" : "RobotTest/test/robot/MediaEngine.robot",
     "timeoutInMinutes" : 900,
     "controllerDemands": "- HIVE_ES_DEDICATED_LAN -equals Yes",
     "esConfiguration" : "platform:\n  module: qualcomm\n  type: CRD\n  chipset: 8280\ncontroller:\n  osgServiceAccount: true\npipeline:\n  tags:\n    - mediaTests\n    - prod\nqrd:\n  usePrebuiltPkgs: true"
  }
}

Attempted various combinations of demands such as:

"demands" : "RANDOM_DEMAND"
"demands" : "RANDOM_DEMAND=Yes"

And they were just ignored as far as I can tell.

huserben commented 7 months ago

Thanks for the investigation. I believe the demands should be an array with entries in the form of "name" and "value".

So something like this:

    "demands": [
        {
            "name": "RANDOM_DEMAND"
        },
        {
            "name": "HIVE_ES_DUT_CHIPSET",
            "value": "8280"
        }
    ]