Build number missing at start of build message
Opened this issue · 10 comments
The starting build message shows #??? as the build number, rather than the actual build number.
Build Server Code :: Docs on branch refs/heads/master has started.
This is build number #??? and was triggered by Joseph Lust. TeamCity: 9.0.1 (build 32116)
Plugin: latest
SCM: git
Runner: Maven
Note: The end of build message does show the proper build number:
Build Server Code :: Docs on branch refs/heads/master was successful.
It was build number #0a27596085b9d03bb60d1f239df873283f9936f3 and was triggered by Joseph Lust. Note: This only happens if I rerun a build. Perhaps TC doesn't know how to uniquely identify it after the git hash has already been assigned to a preceding build.
Hi Joseph
That sounds really strange. I haven't tested the plugin against TC9 yet, but will do so soon and provide feedback as soon as I can simulate the issue.
Thanks @parautenbach. It may be just a defect in the underlying TC9 API, in which case you can close this.
Hi, I'm in the process of updating the plugin and I'm now investigating this issue. Is this still an issue you're experiencing?
I can't reproduce this yet, but I'd like to keep this open, because I can't say with certainty this isn't a plugin issue.
Would it be possible for you to enable the plugin's debug logging? I'm looking for the value of the build ID before it's passed to the template, typically:
2015-04-05 22:07:03,841 - DEBUG - teamcity.build.id: 780I'm seeing this issue with TeamCity 8.1.2, is it possibly a timing issue? We're using build id specified by perforce changelist. My first test of the plugin I re-ran a build so it was re-using the same perforce changelist number. I'll monitor more to see what the behavior is and consider running the plugin with debug enabled.
Would you please enable debug logging and post the line containing teamcity.build.id here? TeamCity 8 is quite old. Is there a possibility for you to upgrade?
We've since updated to TeamCity 9.1, but We've since changed the settings on this to only send notifications for failed builds. I don't want to change this for testing as it's a server wide setting.
Without issue 18 completing, I can't test this without negatively impacting the entire company. Additionally without 18, we're just not really using the plugin much in the first place instead of alternatives.
Thank you. I've responded on issue #18 too.
Without more information there is really nothing I can do, as I can't reproduce this issue. You could always spin up a test server on your side in a VM to try and reproduce the symptoms.
Hi Pieter, the problem is still there. We use TC 10.0.3, but it existed with the previous versions too. As I understood by comparing our different prrojects in TC, this can be related to a couple of things (in our case at least):
- it is reproducible if we use a 'non-default' numeration of a build - for some projects we use Advanced Shared build number plugin. So, this plugin can require additional time to create and assing a build number for a build
- for some builds I see it can be related to dependencies on other builds. Again the problematic build is getting a build number by combining different values including dependent build id. So, this can affect this somehow too. If you need help, please inform me how to gather information for your further investigation.
Good luck! Dmitry
What we use at the moment:
TC - 10.0.3 (build 42434)
HipChat Notifier 0.9.2
And confirm that it works fine with the build which is numerated bby using default values (like build.counter and so on) and in the case when a build is completed - it sends the right build id, so the issue is for just started builds only