Skip to content
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

Open
elliottkopp opened this issue Sep 12, 2014 · 14 comments
Open

Error when TeamCity API doesn't return startDate #3

elliottkopp opened this issue Sep 12, 2014 · 14 comments

Comments

@elliottkopp
Copy link

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:inupdate_builds'
/home/lunchbox/tsm_dashboard/jobs/teamcity.rb:31:in block (2 levels) in <top (required)>' /home/lunchbox/tsm_dashboard/jobs/teamcity.rb:30:ineach'
/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:incall'
/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:inblock 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:inblock in trigger_job'

@elliottkopp
Copy link
Author

Some Googling turned out that the startDate isn't an attribute anymore, it's an element since TeamCity 8.1.

stack72/TeamCitySharp#66

@jurre
Copy link
Contributor

jurre commented Jan 6, 2015

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.

@jsi
Copy link

jsi commented Feb 5, 2015

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.

@jurre
Copy link
Contributor

jurre commented Feb 5, 2015

hi @jsi I'm not sure, we've moved our CI to travis so I have no setup to test this currently..

We could try to access the API directly with something like httparty?

@jsi
Copy link

jsi commented Feb 9, 2015

Hi @jurre !
Thanks for following up. I'm totally new to Ruby. I was just looking for some way of monitoring the builds of our TeamCity Java projects. After reading the code more closely, I am not so sure anymore if the teamcity-ruby-client is the fault. At least it seems likely that a workaround in the widget code should be possible, and it would be less work than rewriting for another module. Have you looked at it? You are the expert here. :)

@jurre
Copy link
Contributor

jurre commented Feb 9, 2015

Hi @jsi, could you check what fields the build contains for you? Something like this should work:

In jobs/teamcity.rb

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

@jsi
Copy link

jsi commented Feb 10, 2015

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 teamcity.scss file:

  &.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.

@jsi
Copy link

jsi commented Feb 10, 2015

I guess this is not as good a solution as your original, but it is good enough for us, right now.
Thank you @jurre for your helpful guidance to solving this problem! Hopefully the changes I have made can be helpful to you or others trying to use this project.

@jurre
Copy link
Contributor

jurre commented Feb 10, 2015

Great, glad you got it working @jsi!

@CatsLoveJazz
Copy link

Is it possible to make an API call such as: httpAuth/app/rest/builds/buildType:myProject as this appears to have the startDate field? Thanks

@jurre
Copy link
Contributor

jurre commented Mar 5, 2015

Maybe? Could you try and let me know?

@CatsLoveJazz
Copy link

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.

@CatsLoveJazz
Copy link

Here's a solution. It turns out there's a difference between builds and build...

  builds = TeamCity.builds(count: 1, buildType: build_id).first
  build = TeamCity.build(id: builds.id).
  buildTime = DateTime.parse( build.startDate )
  puts buildTime.strftime("%d-%m-%y at %H:%M")

@jsi
Copy link

jsi commented Mar 12, 2015

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.

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

No branches or pull requests

4 participants