Glossary
This section provides an alphabetical list of basic terms and their definitions, that will help you successfully work with TeamCity plugin for IntelliJ Platform.
Build Agent
A TeamCity Build Agent is a piece of software that actually executes a build process. It is installed and configured separately from the TeamCity server. TeamCity server monitors all the connected agents and assigns queued builds to the agents based on compatibility requirements defined in corresponding build configuration. To create a build, TeamCity tries to select the fastest agent based on the history of builds of a build configuration which ran on the particular agent. Learn more in TeamCity Online Reference: Build Agent.
Build Configuration
Build Configuration describes a class of builds of a particular type, or a procedure used to create builds. Examples of build configurations are integration builds, release builds, nightly builds, and others. Build configuration are created in the TeamCity web UI by users with corresponding permissions.
Learn more in TeamCity Online Reference:
Build Grid
A pool of computers (Build Agents) used by TeamCity to simultaneously create builds of multiple projects.
Build Queue
A list of build configurations that TeamCity will distribute to compatible build agents as they become available.
Learn more in TeamCity Online Reference:
Change
Any modification of the source code which you introduce. If a change has been committed to the version control system, but not yet included in a build, it is considered pending for a certain build configuration.
Personal Build
A personal build is a build initiated by the Remote Run command, it allows you to safely test your recent changes to the source code without affecting an "actual" build. If a personal build fails, no "real" build is affected. The developer is immediately notified with cause of the failure and can roll back to the state effective at the moment of personal build start. If the build is successful, TeamCity automatically commits the changes to your Version Control system.
You can use the pre-tested commit feature to automatically check modified code into version control if it builds successfully. See Pre-tested Commit.
Pre-Tested (Delayed) Commit
Pre-tested commit is an approach that helps avoid getting defective code into a build, thus saving the entire team from the hassle of broken builds.
When you perform a personal build, you can enable the pre-tested commit feature. With this option selected, your changes are sent to the TeamCity server, and the build is added to the build queue. At the same time, TeamCity copies your changes to a shelveset. When the server is notified that the build was successful, TeamCity automatically commits your changes to source control from the shelveset. In the event of a successful commit, TeamCity removes the shelveset. Thus, if your commit fails for some reason, you can find your changes on the shelveset named Pre-tested commit added <date> <time>.
A pre-tested commit will fail in the following situations:
If the build fails any tests
When the build fails a test the developer is notified, and can immediately start working on fixes locally.
If any conflicting changes are encountered
Conflicting changes occur if somebody commits changes to any of the files after your pre-tested commit, but before the TeamCity client is notified that the build was successful. In this case you should resolve conflicts locally by getting the latest revision from version control and re-running the pre-tested commit). If such a conflict occurs, you can find the pre-tested and committed changes in the appropriate shelveset.
Project
Project is a collection of build configurations. The project has a name (usually corresponds to the name of a real project) and can have some meaningful description.
Remote Debug
Remote Debug allows debugging tests on the TeamCity agent machine remotely, from the IDE on the local developer machine. It is useful when the agent environment is unique in some aspect, which causes a test to fail, and it is difficult to reproduce the problem locally.
Remote Run
See Personal Build.
Shelveset
A shelveset is a set of files that are saved but are not yet ready to be committed to the VCS. Files can be shelved in order to save pending changes to the workspace, or to be shared with other team members for feedback. You can also use shelved files to hand off partially completed work.
Suitable Build Configurations
Suitable configuration is a build configuration on TeamCity server that can be used to verify your changes. The TeamCity plugin looks for suitable configurations in two cases: when you perform a personal build, and when you want to filter your changes by project.
If the TeamCity plugin cannot find suitable configurations, check that:
your VCS settings in IDEA correspond to the VCS settings in TeamCity,
you have the view and run build permissions for the target project.
Version Control System (VCS)
A Version Control System (VCS) is a system for tracking the revisions of the project source files. It is also known as SCM (source code management) or a revision control system.
VCS Root
VCS root is a collection of VCS settings (paths to sources, login, password, and other settings) that defines how TeamCity communicates with a version control (SCM) system to monitor changes and get sources for a build.