结合构建服务器的Maven-release-plugin工作流疑问

我在使用maven-release-plugin时遇到了一些问题，尤其不清楚结合构建服务器（Bitbucket Pipelines）时的预期工作流。以下是我的pom.xml配置：

<?xml version="1.0" encoding="UTF-8"?>
<project ...">

    <scm>
        <url>https://bitbucket.org/our-company/our-project</url>
        <connection>scm:git:git@bitbucket.org:our-company/our-project.git</connection>
        <developerConnection>
           scm:git:git@bitbucket.org:our-company/our-project.git
        </developerConnection>
        <tag>2.1.0</tag>
    </scm>

   <properties>
        <java.version>21</java.version>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>

        <maven-release-plugin.version>3.1.1</maven-release-plugin.version>
        <conventional-commits-policy.version>1.0.7</conventional-commits-policy.version>
    </properties>

    <build>
        <plugins>

            <!-- Use the maven release plugin to release new versions.
               - please find the instructions in the readme on how the release workflow actually works.
               - https://maven.apache.org/maven-release/maven-release-plugin/index.html -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>${maven-release-plugin.version}</version>
                <dependencies>

                    <!-- Use the conventional commits version policy to propose next version numbers.
                       - See https://www.conventionalcommits.org/en/v1.0.0/ and https://maven.basjes.nl/ -->
                    <dependency>
                        <groupId>nl.basjes.maven.release</groupId>
                        <artifactId>conventional-commits-version-policy</artifactId>
                        <version>${conventional-commits-policy.version}</version>
                    </dependency>
                </dependencies>
                <configuration>

                    <tagNameFormat>@{project.version}</tagNameFormat>

                    <!-- Set the version of submodules to the same version as the overall project-->
                    <autoVersionSubmodules>true</autoVersionSubmodules>

                    <!-- Use the conventional commits version policy to propose next version numbers. -->
                    <projectVersionPolicyId>ConventionalCommitsVersionPolicy</projectVersionPolicyId>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

和jgitflow不同，我需要手动将所有内容合并到main分支。原本预期执行mvn release:prepare来设置版本号，该操作会创建标签、生成无-SNAPSHOT的版本并推送，同时创建下一个开发版本，Git层面的发布已完成。接着Bitbucket Pipelines会基于标签的构建配置执行mvn release:perform，进而完成mvn deploy。但困惑的是，release:prepare阶段生成了一个未提交的文件，而该文件是release:perform阶段所必需的，请问正确的流程应该是怎样的？

核心问题分析 #

你提到的未提交文件是release.properties——这个文件由release:prepare生成，包含发布的关键元数据（比如标签名、发布版本、下一个开发版本等），release:perform依赖它定位对应的Git标签并构建发布版本。但构建服务器是从Git拉取代码，这个本地生成的文件不会存在，所以直接在Pipeline里跑release:perform会失败。

正确的工作流（适配Bitbucket Pipelines） #

方案1：本地执行完整流程，Pipeline仅做部署（推荐）

这种方式避免构建服务器处理Git版本变更，稳定性更高：

• 步骤1：合并代码到main分支
  手动将所有待发布代码合并到main分支，确保本地拉取的main分支最新且工作区干净。
• 步骤2：本地执行release:prepare
  运行mvn release:prepare，插件自动完成：
  1. 检查工作区状态、依赖可用性
  2. 根据约定提交规则生成发布版本号（移除-SNAPSHOT）
  3. 更新pom.xml为发布版本，提交并创建Git标签
  4. 更新pom.xml为下一个开发版本（带-SNAPSHOT），提交
  5. 推送所有提交和标签到Bitbucket
• 步骤3：Pipeline触发标签构建执行部署
  在Bitbucket Pipelines中配置标签触发流水线，直接运行mvn deploy而非release:perform：

  pipelines:
    tags:
      '*':
        - step:
            name: Deploy Release
            script:
              - mvn deploy -DskipTests
  

  标签对应的代码已经是release:prepare处理后的发布版本，直接部署即可，无需依赖release.properties。

方案2：Pipeline完整执行prepare+perform（需额外配置）

如果必须在构建服务器完成全流程，需解决Git权限和release.properties传递问题：

• 步骤1：配置Pipeline的Git权限
  确保Bitbucket Pipelines拥有仓库读写权限（使用SSH密钥或App Password），允许插件推送提交和标签。
• 步骤2：同一Pipeline步骤中执行prepare+perform
  不要拆分步骤，因为release.properties是本地临时文件，跨步骤会丢失：

  pipelines:
    branches:
      main:
        - step:
            name: Run Full Release
            script:
              - mvn release:prepare release:perform -DskipTests
            trigger: manual # 手动触发，避免自动执行
  

  同一步骤中，release:prepare生成的release.properties会被release:perform直接读取，完成发布和部署。

关键注意事项 #

• 不要拆分prepare和perform到不同环境：release.properties不会提交到Git，跨环境无法复用。
• 确保约定提交规则正常工作：你的配置使用了conventional-commits版本策略，需保证执行release:prepare的环境有完整Git提交记录，能正确解析版本号。
• 保持工作区干净：无论本地还是Pipeline执行，Git工作区必须无未提交修改，否则release:prepare会报错。

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