ci_commit_tag是合规打标的黄金起点，因其唯一对应commit hash、需权限控制且受语义化规范约束；可构建含git标签/流水线id/时间戳的多版本镜像，并自动归档元数据至release.env，同时拦截非法tag确保源头合规。
直接用 CI_COMMIT_TAG 构建合规制品，核心是“不造轮子、不绕弯、不手动干预”——它本身已是 Git 语义化版本的权威来源，天然满足审计对“可追溯、不可篡改、与代码快照强绑定”的要求。
为什么 CI_COMMIT_TAG 是合规打标的黄金起点
它不是时间戳或随机字符串，而是由人工显式打在 Git 提交上的标签（如 v2.4.1-rc 或 release/2026-Q2-final），具备三大审计刚性特征：
- 唯一对应一个 commit hash，回溯路径明确：从镜像 → tag → commit → 代码变更详情
- 创建动作需权限控制（通常限于 release manager），操作留痕可查
- 名称受团队语义化规范约束（如必须含主版本号+环境标识），杜绝模糊命名
构建带多版本号的制品镜像（如 Docker）
企业常需同时携带 Git Tag、构建流水线 ID、时间戳三重标识，既保溯源又利排查。示例写法：
variables: # 主版本号来自 tag，强制非空（避免误触发） IMAGE_VERSION: $CI_COMMIT_TAG # 流水线级唯一 ID，用于追踪本次构建全过程 PIPELINE_ID: $CI_PIPELINE_ID # 精确到秒的时间戳，辅助定位并发构建 BUILD_TIME: $(date -u +%Y%m%d%H%M%S) <p>script:</p>
- docker build -t $REGISTRY/app:$IMAGE_VERSION-$PIPELINE_ID-$BUILD_TIME .
- docker push $REGISTRY/app:$IMAGE_VERSION-$PIPELINE_ID-$BUILD_TIME
生成的镜像名形如：
harbor.example.com/app:v2.4.1-rc-1892345-20260523084412，每一部分都有明确归属和审计依据。
自动触发发布并写入制品元数据台账
仅推镜像不够，合规要求“发布动作有据可查”。利用 rules + artifacts 自动归档关键信息：
publish_release:
stage: release
rules:
- if: $CI_COMMIT_TAG != null # 仅 tag 推送时运行
script:
- echo "RELEASE_VERSION=$CI_COMMIT_TAG" > release.env
- echo "BUILT_AT=$(date -u)" >> release.env
- echo "COMMIT_HASH=$CI_COMMIT_SHORT_SHA" >> release.env
- echo "PIPELINE_URL=$CI_PIPELINE_URL" >> release.env
artifacts:
paths: [release.env]
expire_in: 30 days
该 job 会自动生成 release.env 文件，内容为结构化元数据，可被审计系统直接采集，无需人工填写发布单。
拦截非法 tag，守住合规第一道门
防止开发误打不符合规范的 tag（如 test-v1、fix-bug），可在流水线开头加校验：
before_script:
- |
if [[ ! "$CI_COMMIT_TAG" =~ ^v[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9]+)?$ ]]; then
echo "ERROR: Invalid tag format. Expected semantic version like v1.2.3 or v1.2.3-rc"
exit 1
fi
校验失败则整条流水线中止，从源头阻断不合规制品产生。
