TeamCity是否支持类似Jenkins Pipeline Shared Libraries的脚本复用及导入？

Hey, great question—coming from Jenkins Shared Libraries, you’ll be happy to know TeamCity has solid equivalents to eliminate duplicate pipeline scripts. Let’s walk through the best options for your scenario where only the SCM URL varies across projects:

1. TeamCity Project Templates (Closest to "Inheritance" for Visual Configs) #

This is the most direct way to reuse entire pipeline configurations without writing extra code. Here’s how it works:

• Create a template project: Set up all your common build, test, and deployment steps in a dedicated template project. Instead of hardcoding the SCM URL, define a parameter (e.g., %PROJECT_SCM_URL%) for it in the template’s VCS root settings.
• Inherit the template: For each of your repository-specific projects, choose "Create project from template" when setting up the project. You’ll only need to override the %PROJECT_SCM_URL% parameter with your repo’s URL—all other pipeline steps stay exactly as defined in the template.
• Bonus: Templates support incremental updates. If you tweak the common logic in the template, all inherited projects will automatically get those changes (or you can choose to update them manually if you want to lock in a version).

2. Reusable Logic via TeamCity DSL (Kotlin/Groovy) #

If you prefer code-based pipeline definitions (like Jenkinsfiles), TeamCity’s DSL lets you write shared, reusable code blocks that you can import across projects. This is the closest equivalent to Jenkins Shared Libraries:

• Create a shared DSL script: Write a Kotlin or Groovy script (e.g., CommonPipeline.kt) that defines your core pipeline logic as a function accepting the SCM URL as a parameter. For example:

  fun Project.setupCommonPipeline(scmUrl: String) {
      vcsRoot(DslContext.settingsRoot) {
          url = scmUrl
          // Add other common VCS settings here
      }
      buildType {
          name = "Build & Test"
          steps {
              gradle {
                  tasks = "clean build test"
              }
          }
      }
      // Add deployment steps, triggers, etc.
  }
  

• Import the shared script: Store this DSL script in a dedicated shared repository (or even in a central location within TeamCity). Then, in each project’s .teamcity/settings.kts file, import the shared script and call the function with your repo’s SCM URL:

  import com.yourcompany.CommonPipeline.setupCommonPipeline
  
  project {
      setupCommonPipeline("https://github.com/yourcompany/your-repo.git")
  }
  

• Sync across projects: Use TeamCity’s "External DSL" feature to link all projects to the shared DSL repo, so any updates to the common logic are propagated to all dependent projects.

3. Shared Build Scripts (For Low-Level Step Reuse) #

If you have reusable shell/PowerShell scripts for build/test/deployment logic, you can centralize these in a shared repository and pull them into each pipeline:

• Store scripts in a shared repo: Create a repo with your common scripts (e.g., build.sh, deploy.ps1).
• Check out the shared repo in your pipeline: In each project’s VCS settings, add the shared repo as an additional VCS root, or use checkout rules to pull it into a subdirectory of your main repo.
• Run the shared scripts: In your build steps, execute the shared scripts and pass the SCM URL as a parameter (e.g., ./shared-scripts/build.sh --scm-url=%PROJECT_SCM_URL%).

Quick Recommendation for Your Case #

Since you only need to vary the SCM URL across projects, Project Templates are likely the fastest and simplest solution—you’ll get full pipeline reuse with minimal setup. If you eventually need more flexible, code-driven logic, the DSL approach will feel very familiar coming from Jenkins Shared Libraries.

内容的提问来源于stack exchange，提问作者bp2010