-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when TeamCity API doesn't return startDate #3
Comments
Some Googling turned out that the startDate isn't an attribute anymore, it's an element since TeamCity 8.1. |
Hey, somehow I've totally missed this. Apologies! Do you have an example of what is returned so I can fix this? We don't currently use this widget. |
I still have this problem. Is there any solution on the horizon? To me, this seems to be an issue with the teamcity-ruby-client, not this widget. |
Hi @jurre ! |
Hi @jsi, could you check what fields the In def update_builds(build_id)
builds = []
build = TeamCity.builds(count: 1, buildType: build_id).first
puts build
date = DateTime.parse(build.startDate)
# ... Feel free to hop in one of our hipchat rooms if you have any questions: https://www.hipchat.com/gcjvO7td5 |
Ah. Ruby starts making sense to me now, and so does the first comment of this thread The entire problem is that startDate is not in the build object, so the parse method fails. At least temporarily, I solved this by commenting out the date variable: # date = DateTime.parse(build.startDate)
build_info = {
label: "Build #{build.number}",
value: "#{build.status}",
# value: "#{build.status} on #{date.day}/#{date.month} at #{date.hour}:#{date.min}",
state: build.status
} Also, it looks as if the values in the status-field of the build object has changed. In order to get the red colour on the failed builds, I had to make a change to the &.FAILURE,
&.errored {
background-color: $background-error-color;
}
&.started {
background-color: $background-started-color;
}
&.SUCCESS,
&.passed {
background-color: $background-passed-color;
} The SUCCESS line is not necessary, since that color is default, but it is nice to do it right. |
I guess this is not as good a solution as your original, but it is good enough for us, right now. |
Great, glad you got it working @jsi! |
Is it possible to make an API call such as: |
Maybe? Could you try and let me know? |
I'm not sure if the team-city gem supports this, that's what I was hoping to find out, but I will carry on investigating when I can. |
Here's a solution. It turns out there's a difference between builds and build...
|
Thanks! Great solution @CatsLoveJazz ! But, you had me confused there, with the dot at the end of the second line. I only got it working when I removed it. |
Teamcity 8.1.4 apparently doesn't return a startDate for builds (or our TC instance isn't configured to do so). This causes the date parsing to blow up since the startDate is nil.
scheduler caught exception:
can't convert nil into String
/home/lunchbox/tsm_dashboard/jobs/teamcity.rb:7:in
parse' /home/lunchbox/tsm_dashboard/jobs/teamcity.rb:7:in
update_builds'/home/lunchbox/tsm_dashboard/jobs/teamcity.rb:31:in
block (2 levels) in <top (required)>' /home/lunchbox/tsm_dashboard/jobs/teamcity.rb:30:in
each'/home/lunchbox/tsm_dashboard/jobs/teamcity.rb:30:in
block in <top (required)>' /var/lib/gems/1.9.1/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:230:in
call'/var/lib/gems/1.9.1/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:230:in
trigger_block' /var/lib/gems/1.9.1/gems/rufus-scheduler-2.0.24/lib/rufus/sc/jobs.rb:204:in
block in trigger'/var/lib/gems/1.9.1/gems/rufus-scheduler-2.0.24/lib/rufus/sc/scheduler.rb:430:in
call' /var/lib/gems/1.9.1/gems/rufus-scheduler-2.0.24/lib/rufus/sc/scheduler.rb:430:in
block in trigger_job'The text was updated successfully, but these errors were encountered: