mystictaya.blogg.se

1. #TEAMCITY KOTLIN HOW TO#
2. #TEAMCITY KOTLIN INSTALL#
3. #TEAMCITY KOTLIN PORTABLE#
4. #TEAMCITY KOTLIN CODE#

If ("true".equals(DslContext.getParameter("deploy")))Īs all required context parameters are now in the project DSL, let’s use this specification to create a new TeamCity project for the Bitbucket integration.Īfter you add the project, go to its Versioned Settings and enable the synchronization of the versioned settings with the "DSLDemo" repository. Now, you can perform an extra check and add the DeployIt build type only if the deploy context parameter is set to true in a given TeamCity project: This is how the project DSL would look normally: For example, you may need the "Deploy It" build configuration only in some of your TeamCity projects – not in all of them. Moreover, you can use context parameters to compose custom logic. Url = DslContext.getParameter("fetchUrl")

#TEAMCITY KOTLIN CODE#

A context parameter is declared as follows:Īnd this is how the DSL code above becomes a single source for multiple potential projects: You can add them under Versioned Settings | Context Parameters if versioned settings are enabled for your project. Using context parameters is a good solution to this problem. To make changes in the shared code that the projects have in common, you would have to change it in both projects, which is surely not the best approach. You’d need to copy this whole DSL project and replace the name and url values. But imagine you want to reuse this code in a similar project that, for example, builds a plugin that implements the Bitbucket issue tracker integration. This is how you would specify these settings explicitly, without context parameters. Thus, the VCS root specification should point to the respective repository: The source code of the plugin is hosted on GitHub.

#TEAMCITY KOTLIN PORTABLE#

This file describes the project configuration in the portable Kotlin DSL format. The project is also synchronized with the "DSLDemo" repository, where its settings are stored in the settings.kts file. The "Test It" build configuration contains a VCS trigger that detects changes in the source repository. It comprises three build configurations connected to a build chain. Let’s consider a TeamCity project that builds a plugin for integration with the GitHub issue tracker. You can find a quick text recap of the tutorial below.

#TEAMCITY KOTLIN HOW TO#

In this video, we’ll explore an example project and show you how to utilize the power of context parameters in your DSL projects. This is far more convenient than storing similar DSL specifications in multiple branches or creating a complex project hierarchy in TeamCity. It means that you can create one DSL project template and reuse it in as many projects on the TeamCity server as necessary. These parameters can vary from project to project in TeamCity while the common project declaration stays the same.

#TEAMCITY KOTLIN INSTALL#

Execute the docker run command below to install the TeamCity server with two volumes (teamcity-data-directory and teamcity-log-directory) - names are arbitrary.In version 2019.2, TeamCity introduced the ability to use context parameters in Kotlin DSL project configurations. But in this tutorial, you’ll set up the TeamCity server as a Docker container.ġ.

There are three different options in setting up the TeamCity server as a package on local machine, as a docker container, and using the TeamCity cloud. But before discovering TeamCity’s untapped potential with CI/CD, you first have to set up the TeamCity server on your local machine or virtual machine (VM). TeamCity is a powerful tool that provides automated responses to code changes. Related: A Beginner’s Guide to Visual Studio Code and Git Installing JetBrains TeamCity Server on Ubuntu

If you’d like to follow along, be sure you have the following: This tutorial will be a hands-on demonstration. Installing JetBrains TeamCity Server on Ubuntu.