Skip to end of metadata
Go to start of metadata

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.

On this page:

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:

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

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

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.



See also:

1 Comment

  1. A question in the community forum on project vs build configurations.