filter mismatch when using default quick filter Default VSC Branch only
jtognazzi opened this issue · 16 comments
Expected Behavior
Quick filter: works out of the box
Current Behavior
When adding the quick filter Default VSC Branch only
, no notification are sent and the following error is reported
702 :: Filter mismatch: ${branchIsDefault} (${branchIsDefault}) does not match using regex true
I'm pretty sure it used to works, so it might be related to the TC server version.
I first had tcWebHooks Version: 1.20 but I also installed the latest stable release 1.25 and it shows the same behavior.
Steps to Reproduce (for bugs)
- Create a Webhook to trigger when build fails
- Add the quick filter
Default VSC Branch only
Your Environment
- tcWebHooks Version: 1.25
- TeamCity Version: 2023.11.3 (build 147512)
- TeamCity server Operating System: Windows Server 2016
- Are you using a WebHook Template?: Microsoft Teams (JSON Standard template)
Example Configuration (xml)
<?xml version="1.0" encoding="UTF-8"?>
<settings>
<webhooks enabled="true">
<webhook id="id_252346741" url="<removed>" enabled="true" template="microsoft-teams" hide-secure-values="true">
<states>
<state type="buildAddedToQueue" enabled="true" />
<state type="buildRemovedFromQueue" enabled="true" />
<state type="buildStarted" enabled="true" />
<state type="changesLoaded" enabled="true" />
<state type="buildInterrupted" enabled="true" />
<state type="beforeBuildFinish" enabled="true" />
<state type="buildFinished" enabled="true" />
<state type="buildSuccessful" enabled="false" />
<state type="buildFailed" enabled="true" />
<state type="buildFixed" enabled="false" />
<state type="buildBroken" enabled="false" />
<state type="responsibilityChanged" enabled="true" />
<state type="buildPinned" enabled="true" />
<state type="buildUnpinned" enabled="true" />
<state type="reportStatistics" enabled="false" />
<state type="serviceMessageReceived" enabled="true" />
</states>
<build-types enabled-for-all="false" enabled-for-subprojects="false">
<build-type id="bt26667" />
<build-type id="bt26671" />
<build-type id="bt26672" />
</build-types>
<trigger-filters>
<filter value="${branchIsDefault}" regex="true" enabled="true" />
</trigger-filters>
</webhook>
</webhooks>
</settings>
Firstly. thank you for your excellent bug report. It has everything I needed to check.
I did as you indicated and created a Quick Filter for default branch.
When run, it works correctly.
Can I ask you if the error 702 above is from an actual running build or from testing the UI somewhere?
My trigger filters looks the same as yours, so I can't see anything that you're doing wrong.
<trigger-filters>
<filter value="${branchIsDefault}" regex="true" enabled="true" />
</trigger-filters>
My version 1.2.5 is built from a different branch so I'll get the officially released one and try again. I'll try to get back to you tomorrow with an update.
I now have 1.2.5 release installed but I can't reproduce this issue.
I wondered if it might be because the build needed to fail, but I found a build that fails on main
and that still works correctly for me.
Can you please check that the VCS is set as having branch support? Does TeamCity show you multiple branches in the UI like this?
Hi, thanks for your prompt reply !
So, yes the project is showing the multiple branches in the UI,
but I just noticed that the main branch does not show up like the other branches:
On other project it shows main
there.
Maybe, this is causing the issue...
I'll have a look at the configuration in detail to see if something is missing...
Ok, when I look in the parameter tab of one of this build, I see I don't have this one:
teamcity.build.branch.is_default
So, I guess that's why it is failing
I have that value, but it's set to false for non-main builds.
Thanks for your help.
I think we can close the issue.
The plugin is not responsible for the error. It is really link to my custom build configuration
Thanks for the update. I'll close it out. Thanks for using tcWebhooks.
I do have a question though:
Is it possible to test if a variable exists with the filter configuration ?
Reading the doc, I didn't find anything...
I'm not sure I really understand the question.
Are you asking if the UI can check if a variable exists when we configure the filter?
Or are you referring to other variables? Eg, ones that are defined on the build or payload?
Or perhaps you are asking whether it's possible to check if the variable is defined?
Yes, I would like to add a filter in the webhook configuration to check if the teamcity.build.branch is defined
What behaviour would you like if the filter does not find the value? Prevent the webhook or send the webhook?
I would like to send the webhook only if the variable does not exits.
But, if this is not possible, I will find another way.
Here are a couple of things you could try. I can't easily get a value that doesn't exist, other than referring to values that are non-existent. However, this means that I can't test both positive and negative scenarios.
In this first example we utilise regex's negative lookahead to look for something that does not contain .+
(which means at least one character). In other words, something that is empty.
${teamcity.build.something.nonexistant}
:: ^(?!.+)$
However, this might not work because the template engine (Standard) used by the MS Teams template will actually return UNRESOLVED
for any variable it can't resolve. If this was a Velocity template, that would probably have been the correct approach.
With this information, we can actually look for "UNRESOLVED" and you might have better success.
${teamcity.build.something.nonexistant}
:: UNRESOLVED
In my testing this appears to work.
So for you, you could try ${teamcity.build.branch}
:: UNRESOLVED
eg,
BTW, you can test this from the Preview & Test
tab when editing a webhook. Just choose a build from the history that has or does not have that value set. This might be more convenient than triggering builds all the time.
To test the Filters, you will need to click the "Send Test Webhook for BuildEvent" button. The preview does not test the filters.
Checking for UNRESOLVED works !
Thanks for the detailed explanation, for your time and for this plugin !
That's fantastic. Thanks for the update.