Teamcity plugins install#
Teamcity plugins code#
Teamcity plugins zip#

For this, add a *.jar file with your code to the same kotlin-dsl directory.

If your plugin implements a major addition to the TeamCity functionality and requires an arbitrary DSL extension that cannot be expressed using the recommended approach, you have an option to write a completely custom extension.

This is a recommended approach which covers most use cases and can be properly processed by TeamCity. Refer to the sections below for more information on expected syntax.Įach extension must be described in its own *.xml file inside the kotlin-dsl directory. Inside the kotlin-dsl directory, create an *.xml file and describe a specific extension.

Teamcity plugins zip#

Inside the plugin's ZIP package, create the kotlin-dsl directory. With extensions, you can create a custom class library for your plugin, and TeamCity will handle the DSL generation and conversion when the plugin functionality is used in DSL-based projects. Typed parameters for each specific functionality Ĭontrolled validation and proper compilation ĭSL extensions are natively mapped onto the UI settings and displayed in the 'View DSL' mode Īfter each UI change, versioned settings are updated using the plugin-specific DSL syntax. This provides the following benefits for DSL-based projects: Extensions define a plugin-specific DSL syntax for settings (for example, of a build runner or a project feature implemented by the plugin). Cloud-hosted agents are created, started, stopped, and deleted depending on queued builds.Īllows TeamCity to automatically assign investigators for build problems and test failures.TeamCity allows writing custom Kotlin DSL extensions for plugins. Sources on GitHub | TeamCity DocumentationĪllows you to set priorities for build configurations.Īllows you to clean files created during a build.Īllows you to limit the number of running builds that use the same shared resource (for example, an external database or a server with a limited number of connections).Īllows users with corresponding permissions to pause and resume build queues.Īllows TeamCity to automatically send build statuses of your commits to an external system (GitHub, GitLab, Azure DevOps, Bitbucket, and others).Īllows you to host TeamCity build agents on VMware vSphere/vCenter cloud. Sources on GitHub | REST API DocumentationĪllows TeamCity to parse XML-based report files produced by external tools and display these reports as build results. The following plugins bundled with TeamCity are developed by JetBrains and are open-sourced under Apache 2.0 license.

Teamcity plugins install#

You may also find Gradle TeamCity plugin useful, which supports agent and server-side plugins, and helps to download, install a TeamCity server, perform tasks to deploy, start and stop the server and agent. For more details, refer to the section Developing Plugins Using Maven featuring a Maven archetype supported by JetBrains. To quickly create your first plugin with Maven, see Getting Started with Plugin Development. Please refer to corresponding section for further details. Use the search before posting to avoid possible duplication of discussions.Ĭonsider making your plugin public and submit it to the TeamCity plugins repository. If you need more information or have a question regarding the API, please do not hesitate to post your question into TeamCity Plugins forum. List of existing plugins and bundled open-source plugins TeamCity plugins are written in Java (any JVM-based language like Kotlin or Groovy can be used), run within the TeamCity application and have access to internal entities of the TeamCity server or agent.Īside from this documentation, refer to the following sources: TeamCity functionality can be significantly extended by custom plugins. TeamCity is hiring! Learn about the available vacancies on the JetBrains site.