Kaniko Docker build with semantic versioning from GitLab ci

Question

I am building a Docker image using Kaniko executor, and pushing the built image to a private artifactory. I would like to use semantic versioning to be able to distinguish between later releases/versions, because I expect that multiple versions will follow soon. What is the best method to achieve this?

As for now, my gitlab-ci.yml looks somewhat like this:

stages:
  - build

build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.9.0-debug
    entrypoint: [""]
  script:
    - env
    - KANIKOCFG="\"auths\":{\"$ARTIFACTORY\":{\"auth\":\"$(printf "%s:%s" "${ARTIFACTORY_USER}" "${ARTIFACTORY_PASS}" | base64 | tr -d '\n')\"}}"
    - KANIKOCFG="{ ${KANIKOCFG} }"
    - echo ${KANIKOCFG} >> /kaniko/.docker/config.json
    - /kaniko/executor --dockerfile $CI_PROJECT_DIR/Dockerfile --context $CI_PROJECT_DIR/ --destination $ARTIFACTORY/$REPO/imagename:1.0.0
tags:
    - docker_runner

As seen above, the tagging is hardcoded in the config, it has to be changed manually all the time. As of now, it is:

imagename:1.0.0

Expectation would be if any push would happen to the main branch and merge request is accepted, version would change to for example: 1.0.1 and 1.0.2 and so on...

Tried to check solutions for tagging, but I found so far only advise on using commit tags like this:

stages:
  - build
build:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:v1.9.0-debug
    entrypoint: [""]
  script:
    - /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"
  rules:
    - if: $CI_COMMIT_TAG

(Concern is that custom commit tags would probably make the versioning hard to follow, like "v1.0.1" and "1.2" and "1.3-extended", etc..)

Is there any other solution to this? What would be the best practice?

score 2 · Answer 1 · answered Mar 25 '23 at 13:06

The developers have to provide the information about the nature of the change (breaking change, non-breaking change, bug fix) to the pipeline either by MR source branch name or MR label. The pipeline will auto-generate the semantic version based on that information and store the semantic version in git tags. The image of the executor has to come with tools which auto-generate the semantic version.

I wrote an article on how to Auto Tag Releases with Semantic Versions which gives answers to your questions.

Kaniko Docker build with semantic versioning from GitLab ci

1 Answers1