![]() There are two options to load plugins classes: standalone and shared: TeamCity creates a child Spring Framework context per plugin. WEB-INF/plugins - default directory for bundled TeamCity plugins Plugins with the same name (for example, a newer version) located in /plugins will override the plugins in the /WEB-INF/plugins directory. TeamCity is able to load plugin from the following directories: If you want to get started with an empty plugin quickly, try the Template Plugin in the JetBrains Subversion repository. There is a convention for naming the definition file:īuild-server-plugin- *.xml - for server-side pluginsīuild-agent-plugin- *.xml - for agent-side plugins, where the asterisk can be replaced with any text, for example: build-server-plugin-cvs.xml. TEAMCITY UPGRADE ARCHIVEBean definition files are to be placed into the META-INF folder of the JAR archive containing the plugin classes. Server-side and agent-side plugins are initialized in their own Spring containers this means that every plugin needs a Spring bean definition file describing the main services of the plugin. There are server-side and agent-side plugins in TeamCity. To write a TeamCity plugin, the knowledge of Spring Framework is beneficial. See Installing Additional Plugins and Installing Agent Tools for installation instructions. TEAMCITY UPGRADE HOW TOThink about it, Münchhausen didn't lie.This page is intended for plugin developers and explains how to package TeamCity plugins and agent tools. To solve our problem we decided to add one small improvement: we allowed to specify build parameters references in the artifact dependencies build number:Īnd here is our "Run custom build" dialog where this parameter value can be specified:ĭo you remember that TeamCity allows to publish artifacts in parallel with a build itself? This means that in this dialog you can specify build number of a running build too. In brief this feature allows you to specify values of build parameters when you click "Run" button. Since the last EAP we've improved it a lot. If you are using TeamCity 4.0 EAP, you are probably aware of the new "Run custom build" feature. To do that we have to change the build configuration settings (artifact dependencies) every time we want to upgrade, which is not convenient.įortunately there is a solution. However there is still one significant limitation: we can't choose which build to install. ![]() TEAMCITY UPGRADE UPGRADEAgent waits till the server is up again, sends the produced build log and finishes the build.Īnd now to upgrade our server we just need to click on the "Run" button: Since all of this is done by the build agent running in a separate process the server can be safely restarted. Finally, the script starts our TeamCity server again. TEAMCITY UPGRADE PCThe script is very simple since it is running on the same PC where the server is installed. Then we created a build.xml script which unpacks these artifacts, stops the server, backups the previous installation and installs new files. For security purposes this agent is configured to run one build configuration only (let's call it Upgrade).Īrtifact dependencies in the Upgrade configuration were configured to download the artifacts produced by the build that assembles TeamCity installer. Interested? Well, you can do the same in your testing environment.įirst of all we've installed build agent on the same server where TeamCity is running. ![]() We even have a button in the TeamCity UI which starts the upgrade process. What I mean is that TeamCity server we are using at JetBrains to build our projects now is able to upgrade itself. I think this image is the best illustration of our own TeamCity server upgrade process. This is Baron Münchhausen pulling himself and his horse up from the swamp by his own hair. You probably have seen this illustration before. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |