Project

A project in TeamCity is a collection of build configurations. A TeamCity project can correspond to a software project, a specific version/release of a project or any other logical group of the build configurations. The project has a name, an ID, and an optional description. In TeamCity, user roles and permissions are managed on a per-project basis.

Project Hierarchy

Projects can be nested and organized into a tree allowing for hierarchical display and settings propagation. The hierarchy is defined by the project administrators and is the same for all the TeamCity users. You can view the hierarchy on the overview page, in the Projects popup, and in breadcrumbs.

Settings Propagation

The projects hierarchy is used in the following ways: Settings defined on a project level are propagated to all the subprojects (recursively). These include:

• Parameters

• Clean-up rules

• Versioned Settings (Settings for synchronizing the project settings with version control)

• Since TeamCity 10.0 it is possible to export a project with all its subprojects and external dependencies using the Settings Export page.

Entities defined in a project become available to all the build configurations residing under the project and its subprojects. These include:

• VCS Roots

• Build Configuration Template

• Issue Trackers

• Shared Resources

• SSH keys

• Maven Settings

• Meta-RunnersFor example, if you want to share a VCS root among several projects, you have to move it to the common parent of all these projects. If a VCS root must be shared among all projects, it must be created in the <Root project>.

A setting referencing a project affects the project and all its subprojects. These include:

• User and User group roles

• Investigations

• Muted Problems

• Notification rules

Please note that associating a project with an agent pool is not propagated to its subprojects and affects only the build configurations residing directly in the project.

Root Project

TeamCity always has a <Root project> as the top of the projects hierarchy. The root project has most of the properties of a usual project and the settings configured in the root project are available to all the other projects on the server. The root project is special in the following ways:

• it is present by default and cannot be deleted.

• it is the top-level project, so it has no parent project.

• it can have no build configurations.

• it does not appear in the user-level UI and is mostly present as an entity in Administration UI only.