{"id":405,"date":"2015-02-24T00:00:00","date_gmt":"2015-02-24T00:00:00","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2015\/02\/24\/build-configuration-templates-in-teamcity\/"},"modified":"2017-12-21T10:33:27","modified_gmt":"2017-12-21T10:33:27","slug":"build-configuration-templates-in-teamcity","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/build-configuration-templates-in-teamcity\/","title":{"rendered":"Build Configuration Templates in Teamcity | Teamcity Guide"},"content":{"rendered":"
\n
\n
\n

\"build-configuration-templates-in-teamcity\"<\/h1>\n

Going meta with Meta-Runners in TeamCity<\/h1>\n<\/div>\n<\/div>\n<\/div>\n

<\/a>We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters.<\/p>\n

Meta-Runners<\/a><\/a> provide a straightforward way to create custom build runners. Meta-Runners can be thought of as a way to avoid duplications in build steps across build configurations.<\/p>\n

\n
\n

<\/a>Note<\/h3>\n

<\/a>While templates can be used to create and maintain build configurations that are very similar, Meta-Runners can be used across build configurations that perform the same build steps. Moreover, a build configuration can only be based on one template, but it can make use of multiple Meta-Runners.<\/p>\n<\/div>\n<\/div>\n

In Chapter 3<\/a>, Getting Your CI Up and Running<\/em>, we created the deploy-to-test<\/a> build configuration that deploys the Django application to Heroku. Using this build configuration as an example, we can see how we can extract a Meta-Runner Deploy To Heroku<\/a> that can be used by any build configuration that wants to deploy to Heroku.<\/p>\n

Recall that the deploy-to-test build configuration<\/a> had a simple command-line runner that executed the following commands:<\/p>\n

\n
git remote add heroku git@heroku.com:django-ci-example.git<\/strong>  git push heroku master<\/strong><\/pre>\n<\/div>\n
To create a generic Meta-Runner<\/a><\/a> out of this, we need to provide a way to push to any remote, rather than just git@heroku.com:django-ci-example.git.<\/p>\n
\n
\n
<\/a>Note<\/h3>\n
Deploying to Heroku using remotes needs the ssh<\/a> keys to be set up on the agent. The example used here just illustrates Meta-Runners and may not be ideal for production use.<\/p>\n
<\/a>As mentioned in Chapter 6<\/a>, <\/a>TeamCity for Ruby Projects<\/em>, we can use<\/a> a gem such <\/a>as heroku-headless (https:\/\/github.com\/moredip\/heroku-headless<\/a>).<\/p>\n<\/div>\n<\/div>\n
<\/a>As expected, we will do this by extracting the remote out into a build parameter. The command-line runner will have the following as the <\/a>Custom Script<\/strong> to be run:<\/p>\n
\n
git remote add heroku %heroku.remote%<\/strong>  git push heroku master<\/strong><\/pre>\n<\/div>\n
<\/a>We will provide the value for the %heroku.remote% parameter in the Build Parameters<\/strong> section of the build configuration.<\/p>\n
<\/a>Now we are ready to create a Meta-Runner from this build configuration. This can be done by clicking on the Extract Meta-Runner<\/strong><\/a> button in the right-hand side bar of the build configuration settings page. This brings up the Extract Meta-Runner<\/strong> dialog, which is shown in the following screenshot:<\/p>\n
\"Going<\/div>\n
In the dialog, we<\/a><\/a> give a name to the Meta-Runner. This is the name that will appear in the Runner Type<\/strong><\/a> field when configuring a build step for a build configuration.<\/p>\n
Click on Extract<\/strong><\/a> to create the Meta-Runner. Once the Meta-Runner is created, we can see it listed in the Meta-Runners<\/strong><\/a> tab on the project administration page. We can also edit the Meta-Runner to fine-tune it as desired.<\/p>\n
\n
\n
<\/a>Tip<\/h3>\n
<\/a>A Meta-Runner is essentially an XML configuration (much like most TeamCity configurations) that can be edited directly from the web interface.<\/p>\n<\/div>\n<\/div>\n
<\/a>The following screenshot shows the edit page of the Deploy To Heroku<\/a> Meta-Runner that we just created:<\/p>\n
\"Going<\/div>\n
The <\/a><\/a>Meta-Runner extracts all the parameters and steps defined in the build configuration. We can edit the Meta-Runner to have only the necessary parameters and steps.<\/p>\n
\n
\n
\n
\n
<\/a>Using Meta-Runners<\/h2>\n<\/div>\n<\/div>\n<\/div>\n
We can <\/a><\/a>now use the Meta-Runner that we created pretty much like a normal build runner. We will remove the existing build step in the deploy-to-test<\/a> build configuration (from which we extracted the Meta-Runner) and add a Deploy To Heroku Meta-Runner-based build step.<\/p>\n
\n
\n
<\/a>Tip<\/h3>\n
<\/a>We can also disable build steps if we don’t want to remove them while experimenting.<\/p>\n<\/div>\n<\/div>\n
In the New Build Step<\/strong> page, for the Runner type<\/strong> field, the newly created Deploy To Heroku<\/strong> Meta-Runner is available, as shown in the following screenshot:<\/p>\n
\"Using<\/div>\n
Once we <\/a>choose the Deploy To Heroku Meta-Runner, we can see that the heroku.remote<\/a> parameter is one of the fields to be configured. Since we created the Meta-Runner with the heroku.remote parameter with the value git@heroku.com:django-ci-example.git, that remote is available by default. The Deploy To Heroku runner configuration page is shown in the following screenshot:<\/p>\n
\"Using<\/div>\n
\n
\n
<\/a>Tip<\/h3>\n
<\/a>It is possible to remove the value for parameters in the Meta-Runner XML so that no default values are present for the fields.<\/p>\n<\/div>\n<\/div>\n
We can<\/a> click on Save<\/strong><\/a> to add the build step. The new build step, based on the Deploy To Heroku<\/a> Meta-Runner, will function in the same way as the previous build step based on the command-line runner.<\/p>\n
\n
\n
<\/a>Note<\/h3>\n
<\/a>Of course, the value of Meta-Runners becomes more apparent when we create them out of multiple build steps. The same set of steps that may be repeated across multiple configurations can be extracted into Meta-Runners.<\/p>\n
Reference Book<\/span>\u00a0– Learning Continuous Integration with TeamCity by Learning Continuous Integration with TeamCity<\/span><\/p>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Going meta with Meta-Runners in TeamCity We have seen that build runners can be very handy. Even though most build runners can be replaced with an equivalent command using the command-line runner, build runners come with the convenience of easily setting up build steps, along with the necessary agent requirements and parameters. Meta-Runners provide a…<\/p>\n","protected":false},"author":1,"featured_media":3513,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","_joinchat":[],"footnotes":""},"categories":[2],"tags":[91,1753,1766,1767,679,282,144,1769,1768,315],"class_list":["post-405","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorised","tag-build","tag-build-configuration","tag-build-configuration-templates","tag-build-configuration-templates-in-teamcity","tag-build-management","tag-configuration","tag-teamcity","tag-teamcity-guide","tag-teamcity-tutorial","tag-templates"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=405"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/405\/revisions"}],"predecessor-version":[{"id":3516,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/405\/revisions\/3516"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3513"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}