This EAP build does not have license key bundled with it, please use license key from EAP download page
Before TeamCity 8.0 all project configuration files were stored on disk under
<TeamCity Data Directory>
/config with the following structure:
Project name was used as the name of the directory with all project settings. Project name was also used as the name of artifacts directory under
<TeamCity Data Directory>/system/artifacts for all artifacts produced by builds from this project.
In version 8.0 we're changing this structure. Instead of <project name> we'll use project id and all configuration files will be moved under the projects directory:
Here project id is a new attribute of the project introduced in TeamCity 8.0. The same project id will be used for the directory name under
<TeamCity Data Directory>/system/artifacts. project id can be assigned from the UI on edit project page. During upgrade TeamCity converter will generate these ids based on project names and rename the directories under
<TeamCity Data Directory> accordingly.
These new projects ids are also being used in URLs instead of old "projectXXX" ones, as well as in references to the project in other settings files. Old ids (also known as internal ids) are still in use in the database and other non-settings data.
Old web UI URLs are still being handled - users will be redirected to the new ones, so their bookmarks are safe. However, if you use REST API for accessing projects, you will need to change the URLs in the client.
Before version 8.0, TeamCity server supported the following authentication mechanisms: built-in authentication (enabled by default), Windows Domain (with optional NTLM HTTP authentication), and LDAP. The problem was the authentication modules were mutually exclusive, i.e. it was not possible to have built-in and domain authentication at the same time, although such setup could be convenient during migration from one authentication mode to another. Moreover, if you switched from built-in authentication to domain one, a new set of users was created, thus all the configured user settings, like roles, notification rules and others were lost. Not to mention more advanced cases like the ability to use LDAP connected to Active Directory together with NTLM HTTP (single sign-on scenario).
So we decided to implement a more sophisticated authentication mechanism which we called mixed mode. Starting with this build you can configure several authentication modules, so when the user tries to log in, TeamCity will try all the modules one by one. If one of them authenticates the user, he/she will be logged into TeamCity, if all of them fail to authenticate - he/she won't be able to login. We also implemented a UI to simplify editing of the authentication configuration (in previous versions you had to manually edit main-config.xml file). Finally, we created presets for the most common use cases:
Some modules have settings, these settings can now be edited from the UI too. For advanced users there is an advanced mode allowing to add / remove authentication modules.
On changing authentication modules, all the existing users are preserved.
Additionally, there is a special superuser account with system administrator role. This account is not editable and it does not have a profile, all you can do is change its username or disable it. When server starts, it generates a password for this account and writes it in teamcity-server.log. This account can be used to recover in case if administrator password was lost.
Related topics in our documentation:
We've made several important improvements in the cleanup process:
We already described this feature in our blog post: http://blogs.jetbrains.com/teamcity/2012/12/10/teamhackcity-what-a-bunch-of-teamcity-developers-got-up-to-in-2-weeks/
Now the feature is available in this EAP.
TeamCity IntelliJ IDEA plugin shows status of tests on the TeamCity server right in the editor near the test name:
A couple of other improvements have been done too:
Recently we published a new plugin which allows to limit the number of running builds based on resources availability. Similar functionality has been part of GroovyPlug for a long time but now it got a user interface and new features.
Read more about the plugin here.
Builds schedule tab on the project level shows a schedule of builds triggering based on information in schedule triggers.
We continued improving features related to build problems. In version 7.1 we introduced the concept of a build problem mainly to make it clear why the build failed.
Now we improved it and TeamCity is able to detect whether the problem is a new one in this build or not.
Next to come - abilities to mute problems or assign investigations for them.