search

huserben / TfsExtensions

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

Error: An item with the same key has already been added. #132

Closed SchulzDL closed 3 years ago

SchulzDL commented 4 years ago

I am trying to trigger a second build definition that is in the same project and even saved in the same folder. I am calling the second build definition by the id and it seems to understand that it is a build id and will treat it as such. I am passing parameters and it seems to pick those up but then in the log I see the following errors.

Error message: Error: An item with the same key has already been added. Will wait 1 seconds before retrying request...

This goes on for a few rounds until it just finally gives up...

huserben commented 4 years ago

Hi @SchulzDL

could you provide me the log of the task?

Which version of the task are you using?

Specifying parameters is the most advanced thing so it's likely there might be an issue with the format that the parameters are passed.

SchulzDL commented 4 years ago

logs_81178.zip

FirstBuild.zip

Hi, I have attached the logs and the json definition of the first build that calls the second one. This is using version 3. I also noticed that if I run the same set of two builds on Azure DevOps Services (In the cloud) it works. This is an on premise Azure DevOps Server Update 1 that I have the issue and this is where I need this to run from.

chadlsmith commented 4 years ago

My team is currently experiencing a similar issue when triggering a build between collections.

huserben commented 4 years ago

@SchulzDL

Thansk for the logs and the additional info. As I don't have a DevOps Server to test it could be that something is not compatible, however my understanding is that it should work.

One thing to make sure is that the variables you're setting on are specified as "settable at queue time" in the target build, maybe this is for some reason creating an issue. Another potential issue when looking at your logs is that you set the variables all lower case ("major") while on the target build they are written in all caps ("MAJOR").

@chadlsmith Do you use as well Azure DevOps Server or the cloud version?

Edit: I just tried it out with both trying to set a variable that is not specified as settable at queue time (this works fine) and using a different casing for the variable - with that it failed for me as well on Azure DevOps Services. Coudl you try it again by using the exact same names?

chadlsmith commented 4 years ago

@huserben Thanks for the quick update. I was able to resolve my issue I was using different case (Env vs ENV) for some of my variables. Once i made those match the builds are working without issue.

Just for reference in TFS2017 it was case insensitive but when we upgraded our server to Azure DevOps Server 2019 it seems to be case sensitive.

Again thanks for all of your help.

huserben commented 4 years ago

@chadlsmith Nice to hear it works now. Yes it's possible they made some changes, apparently the server is just refusing the request now (apparently starting from DevOps Server 2019 onwards).

I will leave the issue open until @SchulzDL has verified whether his problem was solved as well and then I'm also planning on updating the documentation with the problem. Due to time constraints I currently don't plan on adding more validation in the task itself.

SchulzDL commented 4 years ago

@huserben Thanks that seems to have be the answer. I changed all the variables and parameters to lower case so there was no question and it works. It is weird that the mixed case seems to work in Azure DevOps Service this is just a change in Azure DevOps Server. That is what really threw me because it was working in the cloud and not on prem. Thanks again.