Versioned TC settings trigger dependent build
Hi,
We've started using versioned settings in TC. We are using a separate git repo for settings.
Our project uses 3 different VCS roots for code: master, release candidates and feature branches (same repository). The project has two subprojects: Build and Test.
Build subproject has one template build configuration and three build configurations derived from it - one build configuration per VCS above.
Test subproject also has one template build configuration. There is one derived build configuration each for feature and release candidate builds. There are three test build configurations for master builds (different SQL Server versions).
The template build configuration defines a daily trigger, but is not attached to any of the VCS roots. Individual derived test configurations attach to their corresponding VCS root. They also define one snapshot and one artefact dependency for corresponding Build build configurations.
Our settings git repository currently has 6 branches in total: master, current, rc-v5.16.0, rc-v5.17.0, rc-v5.18.0, rc-v5.19.0. RC branches correspond to our latest 4 releases and their names are the same as release candidate branch names in our source code git repository (so they get used automatically if we're building patched previous versions)
The problem is that feature and master Test build configurations are triggered by our settings VCS for those rc-v5.XX.Y branches in addition to expected test builds triggered by changes in their source code git repos.
Here's the Test template build configuration Kotlin code:
package test.buildTypes
import jetbrains.buildServer.configs.kotlin.v2019_2.*
import jetbrains.buildServer.configs.kotlin.v2019_2.buildFeatures.commitStatusPublisher
import jetbrains.buildServer.configs.kotlin.v2019_2.buildSteps.MSBuildStep
import jetbrains.buildServer.configs.kotlin.v2019_2.buildSteps.NUnitStep
import jetbrains.buildServer.configs.kotlin.v2019_2.buildSteps.msBuild
import jetbrains.buildServer.configs.kotlin.v2019_2.buildSteps.nunit
import jetbrains.buildServer.configs.kotlin.v2019_2.triggers.schedule
object elements_test_template : Template({
uuid = "21ab50ef-b97a-4cfc-898e-be9f7e44a1ca"
name = "Elements Test Template"
params {
param("system.ZippedBuildFilePath", "%BuildZipFileNameTestable%")
}
vcs {
checkoutMode = CheckoutMode.MANUAL
}
steps {
msBuild {
name = "Install"
id = "RUNNER_32"
path = "integration-tests.msbuild.xml"
toolsVersion = MSBuildStep.MSBuildToolsVersion.V16_0
targets = "Install"
}
nunit {
name = "Unit test"
id = "RUNNER_33"
nunitVersion = NUnitStep.NUnitVersion.NUnit_2_6_3
platform = NUnitStep.Platform.x86
runtimeVersion = NUnitStep.RuntimeVersion.v4_0
includeTests = """
%system.InstallPath%\UnitTests\UnitTests.dll
%system.InstallPath%\UnitTests\Symplectic.UnitTests.dll
""".trimIndent()
excludeCategories = "Integration"
}
nunit {
name = "NUnit Integration tests"
id = "RUNNER_34"
nunitVersion = NUnitStep.NUnitVersion.NUnit_2_6_3
platform = NUnitStep.Platform.x86
runtimeVersion = NUnitStep.RuntimeVersion.v4_0
includeTests = """
%system.InstallPath%\UnitTests\UnitTests.dll
%system.InstallPath%\UnitTests\Symplectic.UnitTests.dll
""".trimIndent()
includeCategories = "Integration"
}
msBuild {
name = "Test"
id = "RUNNER_35"
executionMode = BuildStep.ExecutionMode.RUN_ON_FAILURE
path = "integration-tests.msbuild.xml"
toolsVersion = MSBuildStep.MSBuildToolsVersion.V16_0
targets = "Test"
}
}
triggers {
schedule {
id = "TRIGGER_3"
schedulingPolicy = daily {
hour = 20
}
triggerBuild = always()
withPendingChangesOnly = false
}
}
features {
commitStatusPublisher {
id = "BUILD_EXT_4"
publisher = github {
githubUrl = "https://api.github.com"
authType = personalToken {
token = "credentialsJSON:XXX-XXX-XXX-XXX-XXX"
}
}
}
}
requirements {
moreThan("system.SqlServerVersion", "2008", "RQ_3")
}
})
This is one of the master Test build configurations:
package test.buildTypes
import jetbrains.buildServer.configs.kotlin.v2019_2.*
import jetbrains.buildServer.configs.kotlin.v2019_2.triggers.schedule
object elements_test_master_2014 : BuildType({
templates(elements_test_template)
id = AbsoluteId("elements_test_master_2014")
name = "master 2014: test (SQL Server 2014)"
description = "Install and run tests on SQL Server 2014"
buildNumberPattern = "${elements_build_master.depParamRefs.buildNumber}"
params {
param("BuildZipFileNameTestable", "${elements_build_master.depParamRefs["system.BuildZipFileNameTestable"]}")
}
vcs {
root(master)
}
triggers {
schedule {
id = "TRIGGER_3"
schedulingPolicy = daily {
hour = 20
}
triggerRules = "+:root=${master.id}:**"
triggerBuild = always()
}
}
dependencies {
dependency(elements_build_master) {
snapshot {
}
artifacts {
id = "ARTIFACT_DEPENDENCY_8"
cleanDestination = true
artifactRules = """
%system.BuildZipFileNameTestable% => .
integration-tests.msbuild.xml => .
""".trimIndent()
}
}
}
requirements {
equals("system.SqlServerVersion", "2014", "RQ_4")
}
})
Any idea how to prevent this?
Thank you,
Marko
Please sign in to leave a comment.
Hi,
sorry about the delay. Just to be clear, only 2 branches (the third, based on the same template doesn't) trigger builds when you make changes to your versioned settings on another branch, is that correct?
The builds you shared don't have any VCS Trigger at all, so it doesn't make sense that they trigger when changes happen, much less to the versioned settings on a separate branch. This said, you have shared builds that seem to have some sort of dependency, so if there are other builds somewhere that depend on them, they might be triggered via a dependency. You can check what exactly triggered the builds by accessing the build status page and checking the "Triggered by" field.
Hi,
I may not have explained our scenario well, I'll try to clarify. Our project has two subprojects: Build and Test. Build subproject has a template build configuration and three build configurations derived from it: master, feature branches and release candidates. Each of these build configurations monitors its own VCS root. All VCS roots are for the same repo, just watching different branches: master VCS watches only the master branch, feature branches VCS monitors master branch as the default and +:refs/heads/feature-* branches (e.g. feature-my-new-feature branch), and release candidates VCS monitors +:refs/heads/rc-v* branches (e.g. rc-v5.19.0 branch), with rc-v.3.8.0 (an ancient version) as the default branch.
The Test subproject also has a template build configuration and essentially three derived build configurations: master (this is actually three identical build configs, with different agent requirements), feature branches and release candidates. Each of these has a snapshot and an artefact dependency to the corresponding configuration from the Build subproject.
Test template configuration defines a schedule trigger for 20:00 every day. Since our tests take some time, the idea is to run tests against changed branches for the corresponding VCS root once a day, during the night. All our test builds' Triggered By field reads Schedule Trigger on 03 Mar 20 20:00.
On 06/02/2020, we enabled versioned settings and created a separate git repository for the settings. I've created 4 branches in the settings repository, corresponding to our latest 4 released branches: rc-v5.16.0 - rc-v5.19.0. The names of the branches in the settings repo correspond to names of the branches monitored by our release candidate VCS root, so the correct version of TC settings is used if we need to build a new patch for any of these versions.
Now, it looks as if changes to the master branch in master and feature branches VCS roots result in Test build configurations for master and feature branches being triggered at 20:00 for branches rc-v5.16.0 - rc-v5.19.0 from the TC settings VCS root. Here's one example:
Notice that the code changes are from the master branch on the feature branches VCS root and the test build is run for the rc-v5.16.0 branch from the TC settings VCS root, where TC "detected" changes back from 06/02.
This happens only for master and feature branches Test build configurations. Interestingly enough, Test build configuration for release candidates does show these TC settings changes as Pending, but the schedule trigger does not trigger a build for them:
Kind regards,
Marko
https://youtrack.jetbrains.com/issue/TW-64738