VCS Trigger branch filter ignored

Now clear from https://teamcity-support.jetbrains.com/hc/en-us/community/posts/20174106834578-Gitlab-integration-notify-multiple-build-types

As the integration adds a build to the queue, the build is not “trigger by VCS changes”. The trigger, and its configuration, is ignored (and not even required).

Changing to webhook will perform as expected

Hi,

The settings below do what you describe. BuildDevelop is triggered only on non-default branches, and BuildMain is only on default. Please check.

object BuildDevelop : BuildType({
    name = "BuildDevelop"
    vcs {
        root(DslContext.settingsRoot)
    }
    steps {
        script {
            id = "simpleRunner"
            scriptContent = "echo develop"
        }
    }
    triggers {
        vcs {
            branchFilter = """
                +:*
                -:<default>
            """.trimIndent()
        }
    }
    features {
        perfmon {
        }
    }
})

object BuildMain : BuildType({
    name = "BuildMain"
    vcs {
        root(DslContext.settingsRoot)
    }
    steps {
        script {
            id = "simpleRunner"
            scriptContent = "echo main"
        }
    }
    triggers {
        vcs {
            branchFilter = "+:<default>"
        }
    }
    features {
        perfmon {
        }
    }
})

Hi Anton Vakhtel thanks for the hint!

It wasn't triggering mostly because of the update I shared (using “integration” instead of “webhook”, so there was no Vcs change).

But I've also updated as you mention, it's cleaner.

One thing that is confusing to me however is the delay between Vcs Root getting “Pending Changes” and the build actually triggering.

Most of the times it's 1min but sometimes it's like 2min.

This pops up almost instantly after I “git push” to the branch, but the build is only queued 1 to 2min later, not always the same.

Is it some “quiet” period that can be configured somewhere?

Hi Anton, thanks for the hint.

Yes, quiet period is disabled for this Vcs Root.

“the actual quiet period will not be less than the maximum checking for changes interval”

I had read this part but I couldn't find anything with that wording in the UI.
It refers to the polling interval? It's set to use “default” which is 300 seconds in my case, but whenever the commit hook is triggered/detected, it changes the checking interval to 4h.

I'm not sure I can set less than 60s for polling in this server, but I'll test it…

I changed it to 30s and it didn't change the behavior.

Anyway, it was more of a curiosity as with Jenkins I would get instant build by disabled quiet period.

I can always revert to using jetbrain integration with a no-op build type just to add other build types as dependencies. That would trigger them instantly, but it looks uglier to maintain.

I'll survive with the 1min cooldown, thanks for the help

Hi Anton, I think it's acceptable even though it'd be interesting to understand if it could be fixed yes.

But I'll have to find the time to try to reproduce in a local container first using only demo projects as I'm not an admin of the current instance I'm using to provide all those details.

I'll update this once I managed to do it

I had to setup a local teamcity for another issue so decided to give this a try as well

I used github as VCS: https://github.com/fopinappb/teamcity-integration-test/ and ngrok tunnel on top of teamcity docker to be reachable.

This actually gave me visibility on the time of the request from github webhook to compare with the rest

Relevant logs:

NGROK:

17:12:10.497 WESTPOST /app/rest/vcs-root-instances/commitHookNotification 202

VISUAL PERCEPTION:

two seconds or so before VCS shows that it has been triggered via commit hook and shows pending changes. Build does not immediately start

TEAMCITY SERVER LOG (-1 timezone compared to workstation):

[2024-07-19 16:12:33,276]   INFO - ity.BuildQueuePriorityOrdering - New item Queued build {item id=205, promotion=Build promotion {id=205, configuration={id=Asd_Asd/bt11}}} with weight 0.00 inserted at the default position 0 in the end of the queue
[2024-07-19 16:12:33,279]   INFO - tbrains.buildServer.ACTIVITIES - Build added to queue; Queued build {Build promotion {id=205, configuration={id=Asd_Asd/bt11}, branch=<default>, queued, creatorNodeId="MAIN_SERVER"}, triggered by "Git" (##vcsName='jetbrains.git' type='vcs' triggerId='TRIGGER_1')}

The only thing that it logs is when the build is added to queue. It didn't log anything about the VCS hook being called.

Took 23 seconds to add build to queue

TEAMCITY AGENT LOG:

teamcity-server-testing-teamcity-agent-1-1  | [2024-07-19 17:12:38,550]   INFO - ldServer.AGENT.PollingProtocol - New command is received from server "runBuild" {id = 5494}
teamcity-server-testing-teamcity-agent-1-1  | [2024-07-19 17:12:39,151]   INFO -    jetbrains.buildServer.AGENT -

5 seconds and agent picks up the build

Project / Build config

import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.buildSteps.script
import jetbrains.buildServer.configs.kotlin.triggers.vcs
import jetbrains.buildServer.configs.kotlin.vcs.GitVcsRoot

version = "2023.11"

project {

    vcsRoot(Asd_1)

    buildType(Asd)
}

object Asd : BuildType({
    name = "asd"

    vcs {
        root(Asd_1)
    }

    steps {
        script {
            id = "simpleRunner"
            scriptContent = "cat README.md"
        }
    }

    triggers {
        vcs {
        }
    }
})

object Asd_1 : GitVcsRoot({
    id("Asd")
    name = "asd"
    url = "https://github.com/fopinappb/teamcity-integration-test/"
    branch = "main"
    branchSpec = "+:refs/heads/(*)"
    authMethod = password {
        userName = "fopinappb"
        password = ""
    }
})

It does, thanks Anton.

If I really want it instant, I'll switch over to use the integration again and snapshot dependencies.

Though there I'll lose the “vcs trigger filters”, there'll probably be workarounds.

Cheers