Variable substitution fails for explicitly specified branches #72
Comments
|
Thanks for such a thorough bug report. Yes. There is a chance I am not finding this as "branch build" correctly and maybe not rendering the correct payload. What version of TeamCity and tcWebHooks are you using? Are you using a template? |
|
Currently running TeamCity 2017.1.2 with tcWebHooks 1.1-alpha10.157.147. This happens on our tailored JSON hooks (we're not using any other kind). These are basically all the webhooks for which I documented examples on the wiki: https://github.com/tcplugins/tcWebHooks/wiki/Advanced-Editing-of-tcWebHooks-configuration |
|
Hi @jelco I'm having trouble reproducing this for finished builds. Any suggestions on something I have missed? Here is my setup:
New Webhook created Build Parameters
For I trigger the builds from clicking the run... button and choosing the branch to build. Default Branch (master) Branch named "issue_4-fix_tc10_and_tc2017" |
|
All builds so far were triggered by VCS updates so far, but I've tested with some manualy triggers as well and I'm seeing the same issue. Maybe it helps to have the exact full configuration of one hook that doesn't work? <webhook url="https://api.bitbucket.org/2.0/repositories/.../${project}/commit/${revision}/statuses/build" enabled="true" format="tailoredjson" template="none">
<states>
<state type="buildStarted" enabled="false" />
<state type="buildInterrupted" enabled="false" />
<state type="changesLoaded" enabled="false" />
<state type="buildSuccessful" enabled="true" />
<state type="buildFixed" enabled="false" />
<state type="buildFinished" enabled="true" />
<state type="beforeBuildFinish" enabled="false" />
<state type="responsibilityChanged" enabled="false" />
<state type="buildFailed" enabled="false" />
<state type="buildBroken" enabled="false" />
</states>
<build-types enabled-for-all="true" enabled-for-subprojects="true" />
<trigger-filters>
<filter value="${revision}" regex="^.+$" enabled="true" />
</trigger-filters>
<parameters>
<param name="body" value="{"state": "SUCCESSFUL", "key": "${key}", "name": "${name}", "url": "${url}", "description": "${buildStatus}"}" />
</parameters>
<auth enabled="true" type="userpass" preemptive="true">
<auth-parameters>
<param name="password" value="..." />
<param name="username" value="..." />
</auth-parameters>
</auth>
</webhook>(Of course the username and password have been removed.) |
|
Closer inspection reveals that this issue actually also plays up in repositories that don't have this kind of branch filtering set up. In my current setup I can't really pinpoint a common configuration aspect that doesn't also apply to builds that don't show this issue. My gut feeling tells me that maybe this applies specifically to configurations I created at a specific TC version. There's some really old configs and some really new that don't have it, but I think that maybe all the configurations that have this issue might have been created in the same timespan, at a specific TeamCity version (probably towards the end of version 9). Maybe there's some configuration issue under the hood that didn't get properly converted during an upgrade, affecting the hooks? |
|
Hmm. That's a weird edge case. I'm not even sure how I track that down. Are you able to enable debug logging on the server and get some more info? |
|
Is there anything odd in |
|
Btw. I just tested your example config above and it resolved the project name and revision. |
|
I can't find anything interesting in the project-config.xml files. I'll see what I can find when I switch on TeamCity debug logging. |
|
I'm hoping this helps, because the increased verbosity has made TeamCity barf up this set of stacktraces quite frequently into the logfiles. :) |
|
Yes. I should turn those off. They don't really add much value. I'll go through it when I get to a computer. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm seeing the IllegalArgumentException as described in #26 also occur on finished builds (successful or failed) on specific branches for some of my projects. In general both master and all feature branches work fine, but builds on the "staging" and "production" branches (which are treated differently by some build steps for e.g. deployment logic for nightly resp. stable builds) seem to fail. Note that there is one build configuration which does not differentiate in build steps between the branches but also has this issue.
I think the common denominator is the fact that these build configurations have the branches explicitly configured in their VCS Root. My branch specification on one of the configurations:
The default branch is set to
refs/heads/masterwhich I'm guessing is the reason that branch does not see the issue.In VCS Roots where the branch specification uses wildcards (i.e.
+:refs/heads/*) this issue does not appear.Does this make sense? Could it be you're treating explicitly registered branches differently from default or wildcard matches?
The text was updated successfully, but these errors were encountered: