garuda-common-settings/.gitlab-ci.yml

---
stages: [checks, release]

check-commitizen:
  # Check the current commit message for compliance with commitizen
  stage: checks
  image: alpine:latest
  variables:
    GIT_STRATEGY: none
  script:
    - apk add --no-cache --upgrade py3-pip
    # Pass --break-system-packages since since this containers sole purpose is
    # running 2 applications. If we get to advance this, implement a proper venv
    - pip install --break-system-packages commitizen
    - cz check --message "$CI_COMMIT_MESSAGE" >/tmp/cz_check || true # why does it return 1 if its actually 0?
    - grep "successful" /tmp/cz_check # ugly hack to workaround the above issue
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

tag-to-release:
  stage: release
  # https://gitlab.com/gitlab-org/release-cli/-/blob/master/Dockerfile
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  variables:
    GIT_STRATEGY: none
  script:
    - apk add --no-cache --upgrade git py3-pip
    # Pass --break-system-packages since since this containers sole purpose is
    # running 2 applications. If we get to advance this, implement a proper venv
    - pip install --break-system-packages -U commitizen
    - git clone "$CI_PROJECT_URL.git"
    - cd "$CI_PROJECT_NAME"
    - CHANGELOG=$(cz changelog "$CI_COMMIT_TAG" --dry-run | sed /^Invalid/d)
    - release-cli create --name "$CI_COMMIT_TAG" --description "$CHANGELOG" --tag-name "$CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG != null