![]() Until you do, the project configuration will be inactive in TeamCity. ![]() After the settings have been synchronized, specify the custom values for the context parameters in the Versioned Settings | Context Parameters tab. 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") 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. 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. 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. I tried to write function, which would construct build step pre-filled with default values: fun customAnt(init: AntBuildStep.() -> kotlin.In version 2019.2, TeamCity introduced the ability to use context parameters in Kotlin DSL project configurations. It works as expected, but I want to avoid writing the same repeating parameters for every step over and over again. My settings.kts file looks like this: version = "2018.1" I use TeamCity Kotlin DSL 2018.1 to set up build configuration.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |