Build Type
Represents TeamCity build configuration.
To appear in UI a buildType should be registered in a project using the buildType method.
The id and name are mandatory properties for a valid buildType (id can be omitted if it matches the class name).
BuildType settings are grouped into blocks similar to tabs in the build configuration admin UI:
options available on the General Settings tab are defined as properties
vcs() corresponds to the Version Control Settings tab
steps() - Build Steps tab
triggers() - Triggers tab
features() - Build Features tab
dependencies() - Dependencies tab
params() - Parameters tab
Example. Build configuration with a VCS root, VCS trigger and a single Gradle build step
object RunTests: BuildType({
id("RunTests")
name = "Run unit tests"
description = "Runs all unit tests of the project"
vcs {
root(MyProjectVCSRoot)
}
steps {
gradle {
tasks = "clean build"
buildFile = "build.gradle"
}
}
triggers {
vcs {}
}
})
Example. Build configuration defined in-place
object Main: Project({
name = "Main"
description = "The project main branch"
buildType {
id("Build")
name = "Build"
steps {
gradle {
tasks = "clean build"
}
}
}
})
Example. Composite build configuration
object Aggregate: BuildType({
type = BuildTypeSettings.Type.COMPOSITE
vcs {
showDependenciesChanges = true
}
dependencies {
snapshot(BuildPackage) { }
}
}
See also
Constructors
Properties
If true, viewing of the configuration status is allowed externally. False by default.
Artifact publishing rules. Empty by default, i.e. no artifacts will be published by the build.
Build number pattern. By default "%build.counter%"
Helper for creating references to dependency parameters of this buildType.
Description of a template or build configuration
Enables hanging builds detection. By default true.
Controls whether personal builds can be triggered in this build configuration. True by default.
Checksum of settings that can be set in the build configurations generated by some plugin or REST API script
BuildType or template id. It appears in the web UI and is used in urls. If the entity has a uuid specified, then the id can be changed at any time. If uuid is omitted, then TeamCity treats an entity with a changed id as a new entity, all data associated with the old entity will be lost (e.g. a build history). Id can also be used by some settings, e.g. as a part of parameter reference. If you change the id, you should find all its occurrences in the current project and change them too. Id must be unique across all buildTypes and templates on the server. If id is missing, it will be generated from the class name (if the class is not from the jetbrains.buildServer.configs.kotlin
package).
Allows to set maximum number of simultaneously running builds. Default value is 0 - means there is no limit on a number of running builds. See also maxRunningBuildsPerBranch.
Allows to set maximum number of simultaneously running builds per branch. Each line must be in form of branch:number, where branch is either a logical branch name or a pattern containing and number specifies the maximum number of builds which can be simultaneously running in each branch matching the pattern. 0 means there is no limit.
Defines for which builds artifacts should be published. By default, the artifacts are published for successful and failed builds, but are not published for the cancelled and failed to start builds.
Helper for creating references to reverse dependency parameters of this buildType
Type of this build configuration, when not specified treated as Type.REGULAR
Functions
Configures build clean-up rules
Configures dependencies
Disables settings with the specified ids in this buildType
Configures failure conditions
Configures build features
Configures build parameters
Configures agent requirements
Configures build steps
Validates this object and reports found errors to the provided consumer
Configures Version Control Settings