Default branch trigger setting in UI

[ailjushkin]

Expected Behavior

User set up new project, for instsance, for building base (default) branch and pull-requests automatically.
Pull-request build status is being sent to the BitBucket pull-request and those who had created it, will see if it fails or not.
default branch status is being sent to the devops chat using this plugin webhook, because base branch should be always green.
Devops does not need to watch for feature branches. They set up branch filter for webhook plugin to get alerts only for default branch, not for features.Or turning on the checkbox saying that this webhook is triggered only if it's default branch.

Current Behavior

No branch filter option. No any chance to filter branches. All branch results are triggered.

Your Environment

• tcWebHooks Version: Some latest version
• TeamCity Version: TeamCity Enterprise 2020.1.3 (build 78866)
• TeamCity server Operating System: no info
• Are you using a WebHook Template: yes, look below

There is also a badge saying "The WebHooks REST API plugin is not installed. Most settings on this page will non-functional." but i don't know if it is connected to the problem.

[netwolfuk]

Hi @ailjushkin

That page allows editing of the template content, but that requires the rest API. If you don't want to change any of the template content, then you don't need it.

To filter for specific criteria, you can use a filter. See #117 for more info.

[ailjushkin]

@netwolfuk
Thanks, man, so If I understand it correctly, I have to ask my teamcity admin to add another filter called somewhat vcs_branch_filter which value is regex and default is .* but users in different projects would then overwrite this property through the TeamCity UI?
Expected feature is to fluently apply this fillter in different projects for different branches

[netwolfuk]

Hi @ailjushkin

Your case is actually easier. There is already a webhooks parameter called ${branchIsDefault} so you don't need to create that variable at the top project.

You just need to get the filter added to your webhook checking that that value is true.

I agree it is nicer to have a UI for filters. It's on the road map for 1.2.

[ailjushkin]

Can i do this on a per project basis or this filter is defined globally in teamcity?

[netwolfuk]

It's per webhook configuration. So whenever that webhook would have triggered, it also applies the filter as an extra criteria.

[netwolfuk]

If you wanted to add extra criteria, you can also add another filter. The filters will be ANDed. By that I mean both filters have to evaluate to true for the webhook to trigger.

[ailjushkin]

@netwolfuk sorry man, now I got it, thank you

[netwolfuk]

You're welcome. Sorry it's a pain at the moment. I'm going to put out 1.2 alpha 7 this week, and then the UI for filters is the next ticket I'm working on. It'll be in 1.2 alpha 8, but I don't have an ETA for that yet.

[ailjushkin]

@netwolfuk thanks, so we have tried to write this config

/teamcity_data/.BuildServer/config/projects/<projectid>/pluginData/plugin-settings.xml

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <webhooks enabled="true">
    <webhook url="<url>" enabled="true" format="jsontemplate" template="slack.com">
      <states>
        <state type="buildStarted" enabled="false" />
        <state type="buildFixed" enabled="true" />
        <state type="responsibilityChanged" enabled="false" />
        <state type="beforeBuildFinish" enabled="false" />
        <state type="buildFinished" enabled="true" />
        <state type="buildInterrupted" enabled="false" />
        <state type="buildFailed" enabled="true" />
        <state type="buildBroken" enabled="false" />
        <state type="changesLoaded" enabled="false" />
        <state type="buildSuccessful" enabled="true" />
      </states>
      <build-types enabled-for-all="true" enabled-for-subprojects="true" />
      <trigger-filters>
        <filter value="${branchIsDefault}" regex="^true$" enabled="true" />
      </trigger-filters>
    </webhook>
  </webhooks>
</settings>

We are triggering a non-default branch in a build under the <projectid>/some_subproject (settings are under parent project, not under subproject), but the trigger filter still doesn't work, it sends a message when a non-default branch is failed. Could you please explain, what is wrong with it?

[netwolfuk]

That looks like it should be fine. I'll take a look when I get to the computer and test it.

Maybe best to edit your comment and remove your URL.

[ailjushkin]

@netwolfuk I updated the issue with some details and removed url

[netwolfuk]

HI @ailjushkin

I have coped and pasted your config into my build and it worked correctly for me.
I can see in /webhooks/history.html?view=skipped that the hook is skipped due to the filter.

To be sure can you please check the history page and see what it shows?
Are you sure there is not more than one WebHook configured? Perhaps at the Root level project?

Also, you can please check what the value is for isBranchDefault ?
A good way to do this is to create a new webhook, set the URL to http://localhost:8111/webhooks/endpoint.html?issue=166 and the payload format as Legacy Webhook (JSON) and trigger for success and failure

Trigger a build for your main branch and another branch. After the builds have completed, you can visit /webhooks/endpoint-viewer.html

You should see a big chunk of JSON, and somewhere in there you'll see some values like below.
Non-default branch:

    "branchIsDefault": false,
    "branch": {
      "@class": "webhook.teamcity.payload.content.WebHooksBranchImpl",
      "displayName": "issue_4-fix_tc10_and_tc2017",
      "name": "issue_4-fix_tc10_and_tc2017",
      "isDefaultBranch": false
    },

Default branch:

    "branchIsDefault": true,
    "branch": {
      "@class": "webhook.teamcity.payload.content.WebHooksBranchImpl",
      "displayName": "master",
      "name": "<default>",
      "isDefaultBranch": true
    },

[ailjushkin]

Unfortunately, I see the same result for both branches.

This is our project structure:

<root> - 0 hooks
╚ product - 0 hooks
  ╚ build (Build_Project) - 1 our web hook
    ╚ version 1.2 - 0 hooks
      ╚ webhook test build

Meanwhile the property file is located at:
/teamcity_data/.BuildServer/config/projects/Build_Project/pluginData/plugin-settings.xml

Additionally, I have checked branchIsDefault using legacy webhook and it's "branchIsDefault": true for default branch, and "branchIsDefault": false, for custom branch, which means the flag works properly,

What is the states structure? Does it have to have the state option for branchIsDefault? Not it hasn't.

<states>
        <state type="buildStarted" enabled="false" />
        <state type="buildFixed" enabled="true" />
        <state type="responsibilityChanged" enabled="false" />
        <state type="beforeBuildFinish" enabled="false" />
        <state type="buildFinished" enabled="true" />
        <state type="buildInterrupted" enabled="false" />
        <state type="buildFailed" enabled="true" />
        <state type="buildBroken" enabled="false" />
        <state type="changesLoaded" enabled="false" />
        <state type="buildSuccessful" enabled="true" />
      </states>

[netwolfuk]

Thanks so much for this info. I'll spin up a new TeamCity docker, and install the exact versions you have of everything with the same project layout.

[netwolfuk]

What is the states structure? Does it have to have the state option for branchIsDefault?

The states represent the build events that TeamCity allows me to bind to. WebHookListener registers and listens for these events issued by the teamcity server.
The ones tcWebHooks listens for are:

• responsibilityChanged - This is not really a build event. This is when someone takes responsibility for an already completed build in the UI

These are build lifecycle events

• buildStarted
• changesLoaded
• buildInterrupted
• beforeBuildFinish
• buildFinished

When buildFInished event is triggered, tcWebHooks looks at the result and triggers one of the following pseudo events

• buildFailed
• buildSuccessful

It also looks through previous builds in the history, and tries to determine from previous finished statuses

• buildBroken - This build is failed and the previous was successful. This means it's the first failure since a successful build.
• buildFixed - The build is successful and the previous was a failure. This means it's the first success since a failed build.

They are the events that can you trigger on. Each build has a bunch of context with it. This is the configuration and result at the time the event occurred.
branchIsDefault is one such item of the context of the build at that point in time.

I hope that makes sense. Yes "states" in the config should really be "events". "State" is more like the context of the event.
English is not a great language for this sort of description, since it's too ambiguous. I imagine Russian has more precise terms for these things.

[netwolfuk]

I now have the exact same setup as you, and I am getting the correct result. WebHooks are triggering on the default branch, but not on the feature branches.

• TeamCity Professional 2020.1.3 (build 78866)
• tcWebHooks 1.1.362.398 (Branch: 1.1.x.x Revision: 0a1f1fd)

Can I check how you are configuring your branches? I have my branch specification set as the following:

Also, are there any errors in the teamcity-server.log? Can you enable debug-logging briefly and see if there is anything useful logged when a feature branch build runs?

[netwolfuk]

Also just tested on

• 1.1.374.403 (Branch: 1.1.x.x, Revision: 99409d2)

Everything looks good for me

[netwolfuk]

oh, just checking. Do you have any parameters defined?
If you followed the instructions in #117 you might have created a webhook.branchIsDefault parameter. If so, please remove it. It is not required. tcWebHooks automatically creates the variable ${branchIsDefault} for you.

[netwolfuk]

Hmm. I just tested with webhook.branchIsDefault parameter set to true. It did not interfere with the value set. Sorry, that is not the cause.

[ailjushkin]

Thanks for the detailed explanation of build states, they are definitely look more like events in Russian.

And we have this settings for VCS:

And the %system.subsytem.git.branch% parameter is calculated as develop/%system.teamcity.projectName% where %system.teamcity.projectName% is current project name the build consists in, like 1.2 (root/product/build/1.2 in project structure). So after evaluation of parameter teamcity takes develop/1.2 as default branch.

Also, are there any errors in the teamcity-server.log? Can you enable debug-logging briefly and see if there is anything useful logged when a feature branch build runs?

I will ask our admin to check this out if it is possible

[netwolfuk]

Hi @ailjushkin I tried with the settings you have shown me.

And I pushed to develop/1.2 (and renamed my project to 1.2). It finds and sets my default branch correctly.

But refuses (correctly) to trigger the webhook for non-default branches.

Can you please check if there is anything on your teamcity-server.log? Thanks

[netwolfuk]

Can you also please confirm the tcWebHooks version?

[ailjushkin]

@netwolfuk we have searched through the log for strange things and my colleague found that those project settings are cached on a server and they are not updating until the server is rebooted. It's difficult operation so have we decided to try to store project settings under version control to check whether it solves the problem or not

[netwolfuk]

Thanks @ailjushkin If I understand correctly, the edits you made to the plugin-settings.xml are not being reloaded when the file is edited to add the filter?

[ailjushkin]

@netwolfuk yep, exactly)

[netwolfuk]

ok, that's interesting. This is what I see in the logs when I manually edit that file...

INFO -   jetbrains.buildServer.SERVER - Start reloading projects configuration because of changes in configuration files. 0 new files: [],1 changed file: [/home/netwolfuk/.BuildServer/config/projects/TcPlugins/pluginData/plugin-settings.xml],0 removed files: [] 
INFO -   jetbrains.buildServer.SERVER - WebHookProjectSettingsFactory: re-reading settings for project1 
INFO -   jetbrains.buildServer.SERVER - Finished reloading projects configuration in 476ms, 0  errors

[ailjushkin]

@netwolfuk If I correctly understood our admin, this is because of our "huge" teamcity server. When it comes to an enterprise, things become strange

[netwolfuk]

This can now be done in the UI. Could you take a look and see if this is resolved in 1.2.0 @ailjushkin ?