{"id":406,"date":"2015-02-24T00:00:00","date_gmt":"2015-02-24T00:00:00","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/2015\/02\/24\/going-meta-with-meta-runners-in-teamcity\/"},"modified":"2018-09-25T07:37:38","modified_gmt":"2018-09-25T07:37:38","slug":"going-meta-with-meta-runners-in-teamcity","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/going-meta-with-meta-runners-in-teamcity\/","title":{"rendered":"Going meta with Meta-Runners in TeamCity"},"content":{"rendered":"
\n
\n
\n

\"teamcity-meta-with-meta-runners\"<\/h1>\n

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

Official Reference –\u00a0<\/strong>https:\/\/confluence.jetbrains.com\/display\/TCD9\/Working+with+Meta-Runner<\/a><\/p>\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 i<\/p>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Going meta with Meta-Runners in TeamCity Official Reference –\u00a0https:\/\/confluence.jetbrains.com\/display\/TCD9\/Working+with+Meta-Runner 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","protected":false},"author":1,"featured_media":3508,"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":[449],"tags":[1753,101,1751,1752,1754,144,1755],"class_list":["post-406","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teamcity-build-management-tools","tag-build-configuration","tag-continuous-integration","tag-meta","tag-meta-runners","tag-meta-runners-in-teamcity","tag-teamcity","tag-working-with-meta-runner"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/406","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=406"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/406\/revisions"}],"predecessor-version":[{"id":3509,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/406\/revisions\/3509"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3508"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=406"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=406"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=406"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}