GitLab CI中基于Kaniko实现Docker镜像语义化版本控制咨询

方案1：基于Git提交历史自动生成Patch版本 #

直接统计main分支的提交次数作为Patch版本号，结合固定的Major/Minor版本，自动生成语义化版本。这种方式无需手动维护版本文件，完全依赖Git历史，避免人为错误。

实现步骤： #

stages:
  - build

build-image:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  script:
    # 计算main分支的提交次数作为patch版本
    - COMMIT_COUNT=$(git rev-list --count main)
    # 定义基础版本，可按需调整Major/Minor
    - VERSION="1.0.$COMMIT_COUNT"
    # 配置Artifactory认证并构建推送
    - echo "{\"auths\":{\"your-artifactory-url\":{\"username\":\"$ARTIFACTORY_USER\",\"password\":\"$ARTIFACTORY_PWD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination your-artifactory-url/imagename:$VERSION
  only:
    - main

优缺点： #

• 优点：无需手动维护，版本号与提交次数绑定，直观反映迭代次数
• 缺点：回滚或合并其他分支提交会导致提交次数跳跃，版本号可能不连续

方案2：通过VERSION文件手动维护Major/Minor，自动递增Patch #

在项目根目录创建VERSION文件，内容为当前语义化版本（如1.0.0）。每次合并到main分支时，用脚本自动递增Patch版本，同时将更新后的版本号提交回仓库，确保版本号可控且可追溯。

实现步骤： #

1. 项目根目录添加VERSION文件，初始内容：1.0.0
2. GitLab CI配置：

stages:
  - version-bump
  - build

version-bump:
  stage: version-bump
  image: alpine/git:latest
  script:
    # 读取当前版本并拆分Major/Minor/Patch
    - CURRENT_VERSION=$(cat VERSION)
    - IFS='.' read -r MAJOR MINOR PATCH <<< "$CURRENT_VERSION"
    # 递增Patch版本
    - NEW_PATCH=$((PATCH + 1))
    - NEW_VERSION="$MAJOR.$MINOR.$NEW_PATCH"
    # 更新VERSION文件并提交回仓库
    - echo "$NEW_VERSION" > VERSION
    - git config --global user.name "GitLab CI/CD"
    - git config --global user.email "ci@gitlab.example.com"
    - git add VERSION
    - git commit -m "Bump version to $NEW_VERSION"
    - git push https://gitlab-ci-token:$CI_JOB_TOKEN@$CI_REPOSITORY_URL HEAD:main
  only:
    - main
  except:
    variables:
      # 避免版本提交触发循环流水线
      - $CI_COMMIT_MESSAGE =~ /^Bump version to/

build-image:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  script:
    - VERSION=$(cat VERSION)
    - echo "{\"auths\":{\"your-artifactory-url\":{\"username\":\"$ARTIFACTORY_USER\",\"password\":\"$ARTIFACTORY_PWD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination your-artifactory-url/imagename:$VERSION
  only:
    - main
  needs: ["version-bump"]

优缺点： #

• 优点：版本号完全可控，Major/Minor可根据业务需求手动调整（如新增功能升Minor，不兼容变更升Major），Patch自动递增，避免混乱
• 缺点：需要额外提交VERSION文件到仓库，需配置CI权限避免循环触发

方案3：利用GitLab CI流水线ID作为Patch版本 #

GitLab提供的CI_PIPELINE_IID是项目内唯一自增的流水线ID，每次触发流水线都会加1。直接用它作为Patch版本，实现最简单的自动递增。

实现步骤： #

stages:
  - build

build-image:
  stage: build
  image: gcr.io/kaniko-project/executor:latest
  script:
    # 固定Major/Minor，用流水线ID作为Patch
    - VERSION="1.0.$CI_PIPELINE_IID"
    - echo "{\"auths\":{\"your-artifactory-url\":{\"username\":\"$ARTIFACTORY_USER\",\"password\":\"$ARTIFACTORY_PWD\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination your-artifactory-url/imagename:$VERSION
  only:
    - main

优缺点： #

• 优点：配置最简单，无需额外脚本或文件
• 缺点：版本号与流水线绑定，重试/失败重跑会生成无代码变更的版本；Major/Minor变更需手动修改CI配置

最佳实践建议 #

1. 优先选择方案2：VERSION文件方式最贴合语义化版本控制核心，既保证Patch自动递增，又能手动管控Major/Minor迭代，避免版本混乱。
2. 多标签标记：除语义化版本外，给镜像打上latest标签方便测试环境使用，同时添加$CI_COMMIT_SHORT_SHA标签关联具体提交记录。
3. 权限与校验：使用方案2时，确保CI令牌有仓库写入权限；可添加阶段校验VERSION文件格式，避免非法版本号提交。

内容的提问来源于stack exchange，提问作者Nysa-522