![]() Our new build step was executed and it worked fine. We can see that in the log of the build: Feature branch with extra build steps When I push these changes, the build will start with the settings defined in that branch. Name = "Ensure feature branch is ahead of master" I’ll modify the BlogHelm_CommitStage.kt file by injecting a schell script step at the start, right above the previous first step: I’ll do that with an inline script which just runs “docker version”.įirst, I create a new feature branch out of master, named add-diagnostics-step. Having the pipeline versioned in code means that you can do these changes in an isolated manner.Īs an example, I’ll create a feature branch that has an extra build step which prints out some diagnostic information, e.g. Normally, that would be a chicken-egg problem where your branch would be red until you modify the pipeline, but doing that would cause everybody else’s branch to turn red. This is extremely useful when you have a breaking change in a feature branch which involves a corresponding change to the build pipeline. ![]() This opens up a window of opportunity: we can modify the build pipeline in a feature branch. ![]() Settings still exist in TeamCity, but the ones in our git repository take precedence and override the ones in TeamCity. Now that we have this in our git repository, these settings are leading. I think it’s much easier to start with an existing project and export it, so that you’ll get a taste of what folders and files you get. For example, here’s the DSL for running an inline shell script: In my opinion, it’s more readable than editing XML files (which is an alternative option). I don’t know Kotlin but that’s not a problem because the DSL is simple enough to make sense. Build configurations are under the buildTypes subfolder and the VCS root is under the vcsRoots subfolder. The first subfolder is the name of the project, BlogHelm. It should be straightforward enough: everything is under. teamcity in our repository: Versioned settings ![]() Make sure TeamCtiy has write access to your git repository, otherwise it won’t be able to push these changes.Īfter this is done, we can get latest and see that we have a new folder named. Once you do this, TeamCity will commit to the master branch a bunch of files that describe everything under the project: in my case that’s the two build configurations (Commit Stage and Deploy Stage) but also the VCS root definition of the project. In this form, we enable synchronization, specify the git repository (blog-helm) to use, select ‘use settings from VCS’ and finally use the Kotlin format: Versioned Settings - After the changes In TeamCity, the project had two build configurations: Project with two build configurationsįirst, edit the project and find the versioned settings section: Versioned Settings - Before the changes I’m going to use the blog-helm project that I had configured in the CD with Helm series. And all that is supported in a way that you don’t have to give up the user friendly way of defining your build via the UI. It allows to make changes to the pipeline without affecting other branches. This allows you to change your build configuration in the same way you change your code, via a pull request. In this post, I’ll show how to setup TeamCity so that your project’s build configurations are stored in your git repository. ![]()
0 Comments
Leave a Reply. |