I switched from git-semver to versioningit (reason - to support e.g. test/x.y.z tags) - thank you for configurability!
Example of Dockerhub release: https://github.com/mdomke/git-semver/blob/main/.github/workflows/release.yaml#L27
P.S.
Currently following CI code is running versioning. Feel free to comment :) Either way, Dockerhub releases would simplify code, no need for cache, apk/pip install.
# Following logic is required with chosen release management/promotion method:
# - if we are on an existing tag (e.g. test/1.2.3), use that as the version: 1.2.3
# - if we are past it, predict next version, append commit count and short sha (e.g.1.2.4-4+abc123)
# `test/`` tags are used as primary verion source (see versioningit.toml), since are the most frequent/recent; promotion copies them to integration/, production/
# git-semver does this for SemVer, but does not support named */x.y.z tags, thus a tool that can.
# tried monotag (https://github.com/flaviostutz/monotag) - works but requires shell glue.
# using versioningit (https://github.com/jwodder/versioningit) is all native config
# sample history and expected output:
# commit 4 - tag test/0.2.1 - version generated: 0.2.1
# commit 3 - no tag - version generated: 0.2.1-1+def456
# commit 2 - tag production/0.2.0 - version generated: 0.2.0
# commit 2 - tag integration/0.2.0 - version generated: 0.2.0
# commit 2 - tag test/0.2.0 - version generated: 0.2.0
# commit 1 - no tag - version generated: 0.0.1-1+abc123
# Chosen method of promotion via named tags has inherent possibility of human mistake
# - Same commit MUST be tagged with same version: */x.y.z.
# - One version */x.y.z MUST NOT be applied to multiple commits.
version:
stage: validate
image: python:$PYTHON_IMAGE_TAG # https://hub.docker.com/_/python
rules:
- !reference [.env-rules, rules]
variables:
GIT_DEPTH: 0 # tag reading needs full history
VERSIONINGIT_VERSION: "3.3.0" # https://pypi.org/project/versioningit/
PYTHON_IMAGE_TAG: "3.14.5-alpine"
PIP_CACHE_DIR: $CI_PROJECT_DIR/.cache/pip
APK_CACHE_DIR: $CI_PROJECT_DIR/.cache/apk
cache:
- key: pip-versioningit-$VERSIONINGIT_VERSION
paths: [$PIP_CACHE_DIR]
- key: apk-python-$PYTHON_IMAGE_TAG # auto-invalidates when image tag changes
paths: [$APK_CACHE_DIR]
before_script:
- mkdir -p $APK_CACHE_DIR
- apk add --cache-dir $APK_CACHE_DIR git curl
- pip install "versioningit==$VERSIONINGIT_VERSION"
script:
- versioningit | tee version.txt
after_script:
- |
[ "$CI_PIPELINE_SOURCE" = "web" ] && SOURCE_TAG="[manual]"
PIPELINE_NAME=" - $(cat version.txt) ➡️ $DEPLOY_ENV $SOURCE_TAG"
curl --insecure --silent --show-error --fail-with-body --request PUT --header "Job-Token: $CI_JOB_TOKEN" --data-urlencode "name=$PIPELINE_NAME" "$CI_API_V4_URL/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/metadata"
artifacts:
paths: [version.txt]
expire_in: 1 week
With following config:
# https://versioningit.readthedocs.io/en/stable/configuration.html
[tool.versioningit.vcs]
method = "git"
match = ["test/*"]
default-tag = "test/0.0.0"
[tool.versioningit.tag2version]
rmprefix = "test/"
[tool.versioningit.next-version]
method = "smallest"
[tool.versioningit.format]
distance = "{next_version}-beta.{distance}-{rev}"
dirty = "{next_version}-beta.{distance}-{rev}"
distance-dirty = "{next_version}-beta.{distance}-{rev}"
I switched from git-semver to versioningit (reason - to support e.g.
test/x.y.ztags) - thank you for configurability!Example of Dockerhub release: https://github.com/mdomke/git-semver/blob/main/.github/workflows/release.yaml#L27
P.S.
Currently following CI code is running versioning. Feel free to comment :) Either way, Dockerhub releases would simplify code, no need for cache, apk/pip install.
With following config: