Getting Started / Plugin IntroductionsThe installation instructions for all of our plugins is the same, and pretty straightforward:
- Download the desired plugin ZIP package from the downloads page.
- Place the plugin ZIP package in the $TEAMCITY_HOME_DIRECTORY$/webapps/ROOT/plugins/ directory.
- Restart the TeamCity server.
- Go to Administration | Server Administration | Plugins List and verify that the plugin appears under External Plugins, and is the correct version.
TW-23523. Typically, one can navigate to an authorized Agent, click on "Agent Parameters," and see numerous helpful properties under the System Properties tab that help identify that Agent. "os.arch," "os.name," and "os.version" are the most universal.
On a Windows machine, those three might read "amd64," "Windows 7" and "6.1," respectively. Likewise on a Mac OS X Agent you might see "x86_64," "Mac OS X" and "10.8.1." However, things differ on a Linux Agent:
While this information is technically accurate, "Linux" and "2.6.32-279.5.2.el6.x86_64" are not super helpful in identifying the environment the Agent is running in. On a SuSE machine these values were "Linux" and "3.1.10-1.16-desktop"; on a Debian machine, "Linux" and "3.0.0-17-generic."
Because certain builds may need to run on specific Linux flavors (see: Raw Sockets), filtering the available Agents for a build configuration would require writing rules tied to the Agent name itself, rather than its generic system information. Enter Linux System Properties. An extraordinarily simple (and small), plugin, all it does is add a few additional properties to the Agent environment:
With these simple property additions, one can now quickly identify (and using Agent rules, filter) Agents based on the underlying Linux system information. Currently supported Linux flavors are RedHat, SuSE and Debian, with recognized distributions being RedHat Enterprise, CentOS, SuSE Enterprise Linux, OpenSUSE, Debian and Ubuntu (and its variants). If a Linux flavor or distribution you are using is not supported yet, just request it or consider contributing a patch!
At first users created a separate build configuration, often called something like "Shared Build Number," that was used exclusively for tracking a single build number. Build configurations that needed to share this build number referred to the other build's build number using build parameters. However, this was inelegant, easy to misconfigure, and needlessly used up one of the 20 build configurations that free TeamCity users are limited to.
Then along came the Autoincrementer plugin, which provided a way to share build numbers between configurations. However, this had no user interface (users had to edit an XML file to change the configuration) and kept track of only the shared build counter; formatting still has to be done at each build configuration, which is redundant and easy to misconfigure.
Neither of these solutions had support for dates within build numbers, either. Using the Date Build Number plugin a user could insert a date into the build number format, but the combined configuration was clunky, and the Date Build Number plugin provides no way to customize the date format.
The TeamCity Shared Build Number seeks to fulfill all of these needs, and we believe it does. We are now using it every day to manage the build numbers in our continuous integration environment:
Its simple interface ties in with the rest of the TeamCity administration console, and makes managing build numbers a breeze:
And its tight integration with TeamCity's parameter hinting means configuring builds is fast and simple:
We believe this simple plugin is powerful enough to meet almost any users' needs. However, you can always suggest an improvement, and we would be happy to consider it.
Note: TeamCity and JetBrains are trademarks ™ of and copyrighted © by JetBrains s.r.o. JetBrains is not affiliated with NWTS Java Code. Additionally, JetBrains does not endorse or warrant the statements made on or the software available for download from this site.