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

38 lines
1.5 KiB
YAML

---
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