We've upgraded TeamCity from 2017.1.2 to 2018.2.2 a week ago and then all our builds were showing green even when they went red.
The XML from a few builds via TeamCity 2017.8.2 REST API might look like the following (unimportant fields omitted):
Let's say 5 fails after a few minutes, then it looks like this:
The problem is that in TeamCity 2017.1.2 and earlier, there was a 'running' attribute that was present in the build element, and the code didn't check the 'state' attribute. So after the TeamCity upgrade, we completely lost the pulsing that happens when a build is running. And since the build status started as SUCCESS the first time it was polled, it remained in SUCCESS even after a failure.
We got this working on our own fork by changing the two instances of:
content.attribute('running').present?
To:
content.attribute('state').value == 'running'
This might work for before 2018.2.2, but I've not tried to test against an older system. And there might be a way to secure both if it could be tested I'd spend a little more time submitting a pull request. But it's not clear this project is going to be maintained by Pivotal developers going forward. But at least now there is a record of the issue.
We've upgraded TeamCity from 2017.1.2 to 2018.2.2 a week ago and then all our builds were showing green even when they went red.
The XML from a few builds via TeamCity 2017.8.2 REST API might look like the following (unimportant fields omitted):
Let's say 5 fails after a few minutes, then it looks like this:
The problem is that in TeamCity 2017.1.2 and earlier, there was a 'running' attribute that was present in the build element, and the code didn't check the 'state' attribute. So after the TeamCity upgrade, we completely lost the pulsing that happens when a build is running. And since the build status started as SUCCESS the first time it was polled, it remained in SUCCESS even after a failure.
The problem code is here: https://github.com/pivotal-legacy/projectmonitor/blob/master/lib/payload/team_city_xml_payload.rb
We got this working on our own fork by changing the two instances of: content.attribute('running').present? To: content.attribute('state').value == 'running'
This might work for before 2018.2.2, but I've not tried to test against an older system. And there might be a way to secure both if it could be tested I'd spend a little more time submitting a pull request. But it's not clear this project is going to be maintained by Pivotal developers going forward. But at least now there is a record of the issue.