基于GitLab CI与TBC模板实现Maven项目构建及GitLab Release创建

方案选择建议 #

优先选择TBC Maven模板内置的semantic-release-info任务方案，而非单独使用带Maven插件的semantic-release，原因如下：

• 无缝集成现有流程：TBC的Maven模板已经内置semantic-release的集成逻辑，启用semantic-release-info后，能自动和已有的Nexus部署流程同步版本号，无需额外修改pom.xml或维护两套版本管理逻辑。
• 减少配置工作量：仅通过几个CI变量就能完成GitLab Release触发，无需手动配置semantic-release的Maven插件、版本同步规则等冗余内容。
• 避免流程冲突：单独使用semantic-release Maven插件可能会和TBC模板自带的版本管理、构建流程产生冲突，增加调试成本。

带Maven插件的semantic-release更适合未使用TBC模板的纯Maven项目，对你的场景来说属于冗余配置。

配置GitLab Release的步骤 #

基于TBC Maven模板+semantic-release-info的方案，具体配置如下：

1. 启用核心任务与Release开关 #

在你的.gitlab-ci.yml中，通过变量开启semantic-release信息生成任务，并允许自动创建GitLab Release：

variables:
  # 启用semantic-release版本信息生成任务
  MAVEN_SEMANTIC_RELEASE_INFO_ENABLED: "true"
  # 允许自动创建GitLab Release（默认可能为true，需设为false解除禁用）
  SEMREL_RELEASE_DISABLED: "false"

2. 配置CI权限 #

确保CI Runner具备创建GitLab Release的权限：

• 方式一：使用CI内置令牌
  在项目的Settings > General > Visibility, project features, permissions中，找到CI/CD板块，开启Create releases权限，确保CI_JOB_TOKEN拥有该权限。
• 方式二：使用个人访问令牌（PAT）
  在项目的Settings > CI/CD > Variables中添加变量GITLAB_TOKEN，值为具有api权限的个人访问令牌，需勾选Protect variable和Mask variable。

3. 配置Release附加资源（制品/文件） #

如果需要将构建产物（如jar包）或其他文件附加到GitLab Release，通过TBC的SEMREL_ASSETS变量指定文件路径：

variables:
  # 附加target目录下的所有jar包到Release
  SEMREL_ASSETS: "target/*.jar"
  # 可选：指定变更日志文件，自动填充Release描述
  SEMREL_CHANGELOG_FILE: "CHANGELOG.md"

semantic-release会自动将指定路径的文件上传到GitLab Release中，并使用变更日志内容作为Release的描述信息。

4. 版本号同步说明 #

启用semantic-release-info后，TBC会自动基于语义化提交信息生成版本号，并替换Maven项目中的版本号（无需手动修改pom.xml），确保Nexus部署的制品版本与GitLab Release版本完全一致。

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