MYHOSPITALNOW.COM

Find Trusted Doctors & Hospitals

Discover healthcare providers, compare hospitals, and explore treatment options worldwide.

Free Treatment Quotes • Doctor Search • Hospital Comparison

Find Healthcare Options

www.myhospitalnow.com

TeamCity Meta-Runners: Reuse Build Steps with Parameterized Runner Types

Originally published on 2015-02-24; fully revised and updated.

TeamCity Meta-Runners let you convert repeated build logic into reusable runner types with configurable parameters. This is especially useful for teams managing many similar build configurations and wanting less duplication, fewer copy-paste errors, and more consistent CI behavior.

Official reference: https://confluence.jetbrains.com/display/TCD9/Working+with+Meta-Runner

TeamCity Meta-Runners

What Meta-Runners solve in TeamCity

A standard build runner can execute a task in one build configuration. A Meta-Runner goes further: it packages one or more build steps and exposes parameters so the same logic can be reused in many configurations. This is ideal when multiple pipelines repeat the same deployment, packaging, or environment setup sequence.

  • Reduce duplicated step definitions across build configurations.
  • Expose configurable inputs (for example remote URLs) as parameters.
  • Keep behavior consistent while allowing per-configuration values.

Meta-Runners vs templates vs copied steps

ApproachBest forReuse scopeImportant limit
Build templateStandardizing a full build configuration structureWhole configurationA build configuration can be based on only one template
Meta-RunnerReusing repeated build step logic with parametersOne or more steps across many configurationsNeeds good parameter design and maintenance
Copied command-line stepQuick one-off setupSingle configuration copyHigh drift risk as copies diverge over time

Workflow: extract once, reuse across configurations

flowchart TD
    A[Identify repeated build steps] --> B[Replace hardcoded values with TeamCity parameters]
    B --> C[Validate the original build configuration]
    C --> D[Use Extract Meta-Runner in settings]
    D --> E[Review generated steps and parameters]
    E --> F[Save Meta-Runner at project level]
    F --> G[Add new build step using Meta-Runner type]
    G --> H[Set parameter values per configuration]
    H --> I[Run build and verify output]

Step 1: Parameterize the build step before extraction

The original example deploys to Heroku with a command-line runner. To make it reusable, replace hardcoded values with a build parameter such as %heroku.remote%.

git remote add heroku %heroku.remote%
git push heroku masterCode language: CSS (css)

Define heroku.remote in the build configuration parameters so each configuration can provide its own remote target.

ParameterExample valuePurpose
heroku.remotegit@heroku.com:django-ci-example.gitSelects the git remote used by the deploy step

Step 2: Extract the Meta-Runner

  • Open the build configuration settings that contains the reusable steps.
  • Use the Extract Meta-Runner action from the configuration UI.
  • Provide a clear name (this appears later in the Runner type list).
  • Save and review the generated Meta-Runner under project-level Meta-Runners.

Meta-Runners are represented as TeamCity XML configuration and can be edited from the web interface to keep only required steps and parameters.

Step 3: Use the Meta-Runner in other build configurations

  • Create or edit a build step in another configuration.
  • Select the extracted Meta-Runner in Runner type.
  • Set parameter values for that configuration (for example a different remote).
  • Save and run the build to confirm behavior matches the original step set.
# Example per-configuration parameter value
heroku.remote=git@heroku.com:my-team-app.gitCode language: PHP (php)

Operational notes for Heroku-style git deploys

The original example uses git remote push over SSH from a TeamCity agent. This requires agent-side SSH key setup and is shown as a Meta-Runner illustration, not necessarily as a production deployment pattern. The original source also mentions heroku-headless as an alternative approach.

Common pitfalls and best practices

  • Do not hardcode environment-specific values. Always expose them as parameters.
  • Keep Meta-Runners focused. Prefer small, reusable step groups over very large all-in-one runners.
  • Name parameters clearly. Use predictable keys so teams understand required inputs quickly.
  • Review defaults carefully. Remove unsafe defaults in Meta-Runner XML when accidental reuse could cause wrong deployments.
  • Version and document usage. Track where each Meta-Runner is used to avoid breaking downstream configurations during edits.

Find Trusted Cardiac Hospitals

Compare heart hospitals by city and services — all in one place.

Explore Hospitals
I'm Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms. I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.

Related Posts

What is TeamCity and How it works? An Overview and Its Use Cases

History & Origin of TeamCity TeamCity is a build management and continuous integration server from JetBrains. It was first released on October 2, 2006, and is commercial…

Read More

Top 50 TeamCity interview questions and answers

1) Is TeamCity a CI or CD? TeamCity is a general-purpose CI/CD solution that allows the most flexibility for all sorts of workflows and development practices. The…

Read More

Top Teamcity interview questions and answers

What is the TeamCity tool used for? TeamCity is a CI server written in Java. It allows developers to integrate, code, and is easier to configure with simple…

Read More

Web.config Transformation Using TeamCity explained

Usually Web.config Transformation is being done during a deployment of dotnet application to various server during deployment time. Here Teamcity is a CI server thus deployment can…

Read More

TeamCity EC2 Integration via ISA Server

rajeshkumar created the topic: TeamCity EC2 Integration via ISA Server I have a TeamCity server which is actually installed on SBS 2003 Premium with ISA Server (firewall/proxy)…

Read More

Spring integration tests with Team city: OutOfMemo

rajeshkumar created the topic: Spring integration tests with Team city: OutOfMemo Spring integration tests with Team city: OutOfMemoryError Hello all, On our project we wanted to start…

Read More
Subscribe
Notify of
guest
3 Comments
Newest
Oldest Most Voted
Puja kushwaha
Puja kushwaha
16 days ago

Meta-runners in TeamCity can help teams reuse common build steps and keep pipelines consistent. They are especially useful when several projects need the same setup or command sequence. It is important to give each parameter a clear name and document what the runner expects. Test changes on a sample build before updating shared configurations. This makes reusable steps easier to maintain and reduces the risk of breaking multiple pipelines at once.

Sneha Verma
Sneha Verma
27 days ago

Meta-runners can also help standardize build practices across teams, but access control deserves attention when they handle deployment credentials or environment-specific settings. Keeping secrets outside runner definitions and managing sensitive values through secure parameter storage reduces the risk of accidental exposure in build logs. This becomes especially important when multiple projects share the same automation templates.

Amit kumar
Amit kumar
27 days ago

Reusable Meta-Runners can simplify TeamCity administration, but maintaining backward compatibility becomes important when several projects depend on the same automation. Before rolling out an updated runner, teams should verify its behavior against representative build configurations and confirm that parameter changes will not break existing jobs. Keeping a clear version history and documenting agent requirements makes troubleshooting easier when a shared task starts behaving differently. It is also wise to separate reusable logic from project-specific settings so individual teams can customize their pipelines without creating unnecessary copies of the same runner. This balance helps preserve consistency while allowing build workflows to evolve safely.

3
0
Would love your thoughts, please comment.x
()
x