Skip to content
This repository has been archived by the owner on Mar 24, 2022. It is now read-only.

TeamCity API changes after 2017.1 can force always GREEN #130

Open
hajush opened this issue Mar 12, 2019 · 0 comments
Open

TeamCity API changes after 2017.1 can force always GREEN #130

hajush opened this issue Mar 12, 2019 · 0 comments

Comments

@hajush
Copy link

hajush commented Mar 12, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant