JetBrains TeamCity Blog

Since version 2.0 TeamCity allows to specify the dependencies between the results of the builds of the build configurations, i.e. artifact dependencies and provides dependent builds triggering.

When creating new builds, it’s possible to use the artifacts of:

• last pinned build,
• successful build,
• last finished build (can be useful when integrating with changes third-party libraries)
• build with a particular number

In the artifacts paths you can use regular expressions or file patters. One or several artifacts paths can be specified.
It’s also possible to specify the destination directory where the artifacts are downloaded when the build is started and configure whether to clean the catalogue before creating builds and downloading artifacts to avoid artifacts clutter.

The artifact dependencies are set up when you create or edit the build configuration:

Since TeamCity itself acts like an Ivy repository it allows you to download the artifacts using Ivy tasks or Ivy tool from the command line. The dependencies are specified in the ivy.xml configuration file, you can put the file in your CMS repository and safely test changes in this file when running personal builds. You need to download the Ivy Dependency manager from http://ant.apache.org/ivy/ and follow the steps described in TeamCity online reference.

In the latest TeamCity 3.0 EAP versions we provide a possibility to view the info on the build artifacts were used to create the build on the Build Results page:

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development, artifact dependency, MS Visual Studio 2003, Ivy

In this EAP build we make the introduction to the role-based access to TeamCity features and also provide a number of improvements in other areas.

• The server administrators can now assign roles to users (available in Administration | User Accounts, particular user account page, Roles and Permissions tab):
  
  The already existing TeamCity users get the role of developers for all existing projects. You can find more detailed roles description in the release notes.
  In the nearest EAP releases we will improve the UI to allow assignment of roles to multiple users.
• The long-awaited VCS labeling of sources used in the builds is available for CVS and Perforce:



• Duplicates and Inspections runners now can accept Maven2 projects
• Pre-tested commit is supported for IntelliJ IDEA with StarTeam, ClearCase, and Visual SourceSafe version controls
• Duration charts can now be viewed for each unit test across multiple builds
• Search feature improvements: search by build tags and project/build configuration name is now available
• RSS feeds can now include only only the failed/successful builds or builds with changes of a particular user. The feature is accessible from the My Settings and Tools page:
  
• Possibility to set the frequency of querying the VCS for changes (configurable on the server-wide or a single VCS root basis)
• Ability to request immediate changes checking
• A new area on Administration page: a list of all VCS roots configured in TeamCity
• Support for different URLs for accessing the same SVN server from the TeamCity server and IDEs (no extra configuration is required)

View the more detailed release notes and download the latest build.

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development, MS Visual Studio 2003, Maven2, Duplicates, Inspections, RSS

In fact, this feature existed since TeamCity 1.0, though it isn’t much publicized.

Yes, we admit that we are lazy developers, and we don’t like to restart the programs after editing their configuration files. That’s why IntelliJ IDEA monitors the changes on the disk and reloads files automatically after an external change takes place. And the same is true about TeamCity: it monitors the state of the configuration files and picks up the changes if the files were modified.

FYI: TeamCity server uses XML-based configuration files to store information about system-wide settings, such as authentication scheme, version control roots, third-party reports configuration, etc. The information about configured projects and various build settings is also stored in XML files.

To be more specific:

• After any changes in TeamCity server configuration files, such as main-config.xml, project-config.xml or any *-config.xml, TeamCity reloads the server configuration (it monitors file modification timestamp). The important consequence - when you save these files, they should be in the valid and parseable state. If you are brave enough to manually edit these files, be careful not to break them.
• If you modify the build agent’s buildAgent.properties file, there is no need to restart the build agent. The build agent will wait until currently running build finishes and will restart and reload its configuration automatically.

This is not a killer feature, of course, but it is interesting enough to deserve a separate blog post.

Happy building,

KIR

Technorati tags: TeamCity, JetBrains, Java, .NET, IntelliJ IDEA, continuous integration, build management, agile development