You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 24, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: