Icon

You are viewing the documentation of TeamCity 2018.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

 

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • .BuildServer/config — a directory where projects, build configurations and general server settings are stored
    • _trash — backup copies of deleted projects, it is OK to delete them manually. or For details on restoring the projects check How To...
    • _notifications — notification templates and notification configuration settings, including syndication feeds template
    • _logginginternal server logging configuration files, new files can be added to the directory manually
      Anchor
      projects_folder
      projects_folder
    • projects — a directory which contains all project-related settings. Each project has its own directory. Project hierarchy is not used and all the projects have a corresponding directory residing directly under "projects"
      • <projectID> - a directory containing all the settings of a project with the "<projectID>" id (including build configuration settings and excluding subproject settings). New directories can be created provided they have mandatory nested files. The _Root directory contains settings of the root project. Whenever *.xml.N files occur under the directory, they are backup copies of corresponding files created when a project configuration is changed via the web UI. These backup copies are not used by TeamCity.
        • buildNumbers — a directory which contains <buildConfigurationID>.buildNumbers.properties files which store the current build number counter for the corresponding build configuration
        • buildTypes — a directory with <buildConfiguration or template ID>.xml files with corresponding build configuration or template settings
        • pluginData — a directory to store optional and plugin-related project-level settings. Bundled plugins settings and auxiliary project settings like custom project tabs are stored in plugin-settings.xml file in the directory. Credentials stored outside of VCS per Versioned settings are stored in secure/credentials.json file
        • vcsRoots — a directory which contains project's VCS roots settings in the files _<VcsRootID>.xml
          project-config.xml — the project configuration file containing the project settings, such as parameters and clean-up rules.
    • main-config.xml — server-wide configuration settings
    • database.properties — database connection settings, see more at Setting up an External Database
    • license.keys — a file which stores the license keys entered into TeamCity
    • change-viewers.propertiesExternal Changes Viewer configuration properties, if available
    • internal.properties — file for specifying various internal TeamCity properties. It is not present by default and needs to be created if necessary
    • auth-config.xml — a file storing server-wide authentication-related settings
    • ldap-config.propertiesLDAP authentication configuration properties
    • ntlm-config.propertiesWindows domain authentication configuration properties
    • issue-tracker.xml — issue tracker integration settings
    • cloud-profiles.xml — Cloud (e.g. Amazon EC2) integration settings
    • backup-config.xml — web UI backup configuration settings
    • roles-config.xml — roles-permissions assignment file
    • database.*.properties — default template connection settings files for different external databases
    • *.dtd — DTD files for the XML configuration files
    • *.dist — default template configuration files for the corresponding files without .dist. See below.
  • .BuildServer/plugins — a directory where TeamCity plugins can be stored to be loaded automatically on the TeamCity start. New plugins can be added to the directory. Existing ones can be removed while the server is not running. The structure of a plugin is described in Plugins Packaging.
    • .unpacked — directory that is created automatically to store unpacked server-side plugins. Should not be modified while the server is running. Can be safely deleted if the server is not running.
    • .tools — create this directory to centralize tools to be installed on all agents. Any folder or .zip file under this folder will be distributed to all agents and appear under <agent root>/tools folder.
  • Anchor
    systemDir
    systemDir
    .BuildServer/system — a directory where build results data is stored. The content of the directory is generated by TeamCity and is not meant for manual editing.
    • Anchor
      artifacts
      artifacts
      artifacts — the default directory where the builds' artifacts, logs and other data are stored. The format of the artifact storage is <project ID>/<build configuration name>/<internal_build_id>. If necessary, the files in each build's directory can be added/removed manually - this will be reflected in the corresponding build's artifacts.
      • .teamcity subdirectory stores build's hidden artifacts and build logs (see below). The files can be deleted manually, if necessary, but it is not recommended as the build will lose the corresponding features backed by the files (like the build log, displaying/using finished build parameters including for the build reuse as snapshot dependency, coverage reports, etc.)
        • Anchor
          rawLogs
          rawLogs
          logs subdirectory stores build logslog in an internal format. Build logs store log stores the build output, compilation errors, test output and test failure details. The files can be removed manually, if necessary, but corresponding builds will lose build log and failure details (as well as test failure details).
    • messages — a directory where build logs used to be stored before TeamCity 9.0. After automatic build logs migration to the new place under artifacts, the directory stores the files which could not be moved (see server log on the server start about details).
    • changes — a directory where the remote run changes are stored in internal format. Name of the files inside the directory contains internal personal change id. The files can be deleted manually, if necessary, but corresponding personal builds will lose personal changes in UI and when affected queued builds try to start, they fail or run without personal patch.
    • Anchor
      pluginData
      pluginData
      pluginData — a directory storing various data concerning builds, current system state, etc. It is not advised to delete or modify the directory. (e.g. before TeamCity 2018.2 state of build triggers is stored in the directory). The content of the directory corresponds to the data stored in the database, so when database is restored, this directory should generally be restored to the same state to be consistent with the database.
      • audit — directory holding history of the build configuration changes and used to display diff of the changes. Also stores related data in the database.
      • repositoryStates — before TeamCity 2018.2  was used to store the current state of the VCS roots which were moved to the database in 2018.2. If dropped, some changes might not be detected by TeamCity (between the state last queried by TeamCity and the current state after first server start without this data.
    • caches — a directory with internal caches (of the VCS repository contents, search index, other). It can be manually deleted to clear caches: they will be restored automatically as needed. It is safer to delete the directory while server is not running.
    • buildserver.* — a set of files pertaining to the embedded HSQLDB.

...