Teamcity 如何减少类似构建配置的重复？_Teamcity

Teamcity 如何减少类似构建配置的重复？

teamcity

Teamcity 如何减少类似构建配置的重复？,teamcity,Teamcity,我有几个项目希望在单独的构建配置中使用稍微不同的配置： VCS源和生成触发器（即唯一的区别是使用项目根目录的哪个子目录）构建步骤（前几个步骤完全相同，但后几个步骤可能会有所不同，具体取决于单元测试的运行方式、依赖关系等）就这样。我查看了构建配置模板，但它似乎不允许灵活地指定自定义构建步骤或额外的VCS根实际上，我只是希望不必手动将（几个）构建步骤从初始项目的构建配置复制到多个配置中，并且在情况发生变化时必须对它们进行维护。似乎应该有更好的解决方案？我也想知道这一点，但我在网上找到的信息

我有几个项目希望在单独的构建配置中使用稍微不同的配置：

VCS源和生成触发器（即唯一的区别是使用项目根目录的哪个子目录）
构建步骤（前几个步骤完全相同，但后几个步骤可能会有所不同，具体取决于单元测试的运行方式、依赖关系等）

就这样。我查看了构建配置模板，但它似乎不允许灵活地指定自定义构建步骤或额外的VCS根

实际上，我只是希望不必手动将（几个）构建步骤从初始项目的构建配置复制到多个配置中，并且在情况发生变化时必须对它们进行维护。似乎应该有更好的解决方案？
我也想知道这一点，但我在网上找到的信息表明，您更喜欢冗余，而不是尝试在多个分支或项目中重用一个配置
然而，所有这些都是在版本8发布之前，该版本引入了提取
他们的博客很好地总结了它们是什么以及它们与模板的区别
元跑步者
Meta Runner是一个强大的功能，为定制TeamCity提供了一种很有前途的新方法，使其更加人性化。为了理解这一点，让我们考虑一个例子。假设您有一些重复的任务在不同的构建配置中反复使用。任务定义为一个或多个构建步骤，基于内置的运行程序，如Ant或命令行。您很可能希望在多个构建配置中轻松重用此任务。您不能对模板执行此操作，因为模板强制您在不同的配置中共享相同的设置，这并不总是可能的。我们提出的一个解决方案是从这些步骤中提取Meta runner，请在发行说明中查看它是如何工作的

我还没有实现这一点，但我将很快进行测试。这让我觉得您应该能够将存储库作为一个参数传入，但我不确定。
我已经为此奋斗了一段时间，并开发了一个工具来管理它，我称之为
长期以来，我们一直在使用“模板”项目。基本上，它是一个存储库，它有一个完全工作的应用程序，并具有所需的所有构建配置。很像是。我们有几个模板项目，每种类型的应用程序我们开发一个
这样做的问题是将复制的代码与模板项目保持在synk中
现在，我将模板代码打包在一个“独裁者”中。这样地：
独裁者要求将一些静态文件复制到指定文件夹的根目录

{ "message": "Copy react-boilerplate", "actions": [ { "copyFrom": "react-boilerplate", "target": "." } ] }
可以从命令行运行独裁者，如
npx独裁者react-boilerplate@version
。它将指定当前工作目录，通常是应用程序中的代码库。它可以通过文件中的代码库进行配置。也许选择不听命于某些部分：

{ "ignore": [ "/app", "/package.json", "/package-lock.json", "/Changelod.md" ] }
因此，模板中的大部分构建配置只是复制到指定的代码库中。而
app
文件夹和其他东西仍然由代码库管理
克隆后，文件夹看起来像：

app coverage .dictatorconfig.json docs .gitignore internals LICENSE.md node_modules package.json README.md server

.all-contributorsrc app appveyor.yml babel.config.js Changelog.md CODE_OF_CONDUCT.md CONTRIBUTING.md coverage .dictatorconfig.json docs .editorconfig .eslintrc.js .gitattributes .gitignore internals jest.config.js LICENSE.md node_modules .nvmrc package.json package-lock.json .prettierignore .prettierrc README.md server .stylelintrc .travis.yml
在
npm安装之后或npx独裁者反应之后-boilerplate@version 它看起来像： app coverage .dictatorconfig.json docs .gitignore internals LICENSE.md node_modules package.json README.md server .all-contributorsrc app appveyor.yml babel.config.js Changelog.md CODE_OF_CONDUCT.md CONTRIBUTING.md coverage .dictatorconfig.json docs .editorconfig .eslintrc.js .gitattributes .gitignore internals jest.config.js LICENSE.md node_modules .nvmrc package.json package-lock.json .prettierignore .prettierrc README.md server .stylelintrc .travis.yml 您使用的是哪个TeamCity版本？对我有用。@user1177636是的，我想它最终也会对我的案子有用。我只需要稍微修改一下参数。谢谢你的建议。在对构建参数进行了一点黑客攻击之后，我就能够让它与模板一起工作，但是如果我发现它比它的价值更麻烦的话，这将是一个很好的选择。GitHub上提供了一些元运行程序的示例：@jwalk yah我也听说过同样的事情，你可以通过对它进行黑客攻击使它变得更复杂，以便可重用。另外，您是否使用构建链？您可以让build+unittest=>installer=>autointegration=>deploytoqa。这些链中的许多都可以提取为模板并按原样使用，非常容易。@jwalk我刚刚看到这个问题：我还没有尝试过，但听起来很有希望。我知道这个问题很老，但meta Runner的问题是它们不共享参数；meta runner中的参数本身似乎是“沙盒”。根据我的经验，这大大降低了它们的实用性。例如，我需要一个名为%version% 的参数，该参数跨越多个使用相同版本的元运行程序。从TeamCity 10开始，我必须重新定义每个meta runner中的所有参数。