【问题标题】:File Content Replacer having no effect on artifacts文件内容替换器对工件没有影响
【发布时间】:2015-11-12 18:55:02
【问题描述】:

我正在使用 TeamCity 的一项相对较新的功能:文件内容替换器。在我当前的设置中,我的 VCS 中有一个 version.js 文件:

window["MyPlugin"].version = "1.0.##VCS_REVISION##.##CI_BUILD_NUMBER##";

我使用文件内容替换器构建功能将最后一部分替换为:

%build.vcs.number%.%system.build.number%

到目前为止一切顺利!

我有一个相关的构建步骤。这是一个 MSBuild 步骤,但除了调用 ps1 之外,它什么也不做,它做了两个相关的事情:

  1. 将所有 js 文件移动到“output”文件夹;
  2. 将所有 js 文件压缩到“zips”文件夹中;

这也是我的两个工件(一个输出文件夹和一个 zip 文件)。

但是,文件内容替换器会恢复其更改,但这种恢复也反映在工件 nr 1 中,这些文件不受版本控制(即使它们位于我的项目文件夹的子文件夹中)。未还原 zip 文件中的 version.js 文件。

如果我将工件 1 更改为 my/output/folder => all.%build.vcs.number%.zip,那么 zip 文件也将包含恢复状态,而不是我想要的输出。

如何设置 TeamCity 以使工件文件不受此还原的影响? 还是我需要此构建功能以外的其他东西?

我正在使用在 Windows 2012 Server (VM) 上运行的 TeamCity 9.1.3 build 37176 和用于评估目的的默认数据库。我使用 TFS 2013 作为我的 VCS。

PS。我也问过这个on the JetBrains forums

【问题讨论】:

    标签: teamcity teamcity-9.1


    【解决方案1】:

    文件内容替换会在“发布工件”阶段之前还原更改。这是“设计使然”。您可以在构建日志中检查它。但是,您可以在隐藏的工件 .teamcity/JetBrains.FileContentReplacer/ 中找到修改后的文件。
    如果您想将更改的文件作为常规工件发布,您应该创建文件的副本(或像您已经完成的那样打包/归档它)。此外,您可以创建一个脚本,而不是使用文件内容替换器构建功能,该脚本将进行所需的更改,而这些更改不会被还原。

    【讨论】:

    • FWIW,我已提出 TeamCity 功能请求以改进此功能:youtrack.jetbrains.com/issue/TW-43173
    • 是的,这很奇怪。这些类型的操作曾经是 V9 之前的“构建步骤”,它属于 IMO。我认为问题在于 teamcity 如何保留结帐目录,而不是每次都从头开始。 AppVeyor 可以更好地处理这方面的问题,您可以从头开始,但可以指定某些目录,例如 (nuget) 包或 node_modules 等,以便在构建之间“保留”。这是一个比结帐文件夹更好的解决方案,而 FileContentReplacer 在构建完成后“恢复文件”。
    • 这正是 JetBrains 的座右铭出现在我脑海中的时候。您需要回退到 bash 和 sed,而不是仅仅添加这个构建功能。去here,我的朋友。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-01-25
    • 1970-01-01
    • 2017-05-25
    • 1970-01-01
    • 1970-01-01
    • 2022-01-24
    • 1970-01-01
    相关资源
    最近更新 更多