Just finished a complete setup on a self-managed instance of gitlab anc I can confirm that working with the current documentation has been a challenge. Most of the answer are available deep in github issues comments but it would be awesome to have a better support.

@BastLast is your changelog complete? When I run on the pipeline, I get only few commits (while locally it runs for long time). I tried setting GIT_DEPTH: 0 or GIT_STRATEGY: clone but I still get partial results.

@BastLast is your changelog complete? When I run on the pipeline, I get only few commits (while locally it runs for long time). I tried setting GIT_DEPTH: 0 or GIT_STRATEGY: clone but I still get partial results.

Mine was complete after changing those settings

@BastLast any chance I could get a snippet of the steps you're doing in the script ? I want to check if I'm missing something.

semantic-release:
stage: release
image:
name: python:3.10.0
entrypoint: [""]
variables:
GIT_STRATEGY: clone
tags:
- docker
script:
- git config --global user.email $GIT_mail
- git config --global user.name $GIT_username
- git remote set-url origin https://$GIT_username:$GL_TOKEN@repourl
- git checkout main
- python -m pip --no-cache-dir install poetry twine
- poetry config (artifactory authentication)
- poetry install
- poetry run semantic-release version
- poetry run poetry build
- twine upload

i changed a few things because security / closed source software but that's pretty much the whole script

Thanks this worked. I'll try to see if I can PR some documentation!

I have a working example in GitLab now, I'll start working on a PR

I have a working example in GitLab now, I'll start working on a PR

@codejedi365 I know this was a really old comment, but curious if you still use/have that example for Gitlab.

I have a working example in GitLab now, I'll start working on a PR

@codejedi365 I know this was a really old comment, but curious if you still use/have that example for Gitlab.

Recommend reviewing the comments and examples I had on #1046. I've been meaning to get this to resolution but was working a lot of other resolutions after becoming the primary maintainer. Every time I look into this, there is just a lot of nuance to set up GitLab with the token permissions system being different than GitHub.

Hopefully can knock this out over the holidays.

Much appreciated. I feel you on the nuance with Gitlab. FWIW, if you take a first pass I can help test, refine and document.

@jeffcpullen, thanks! I'll let you know when it's ready

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?

I still think there should be some straightforward guide to GitLab CI.

Still in backlog. There is a full workflow example in the issues. GitLab is very nuanced and is in the middle of token permission which makes the "straightforward" guide anything but simple.

Still in backlog. There is a full workflow example in the issues. GitLab is very nuanced and is in the middle of token permission which makes the "straightforward" guide anything but simple.

Understandable. I've just spent an entire day trying to figure it all out:

• python-semantic-release (PSR) config's parameters (differs from JS semantic-release (SR))
• GitLab personal access tokens vs. project access tokens
• protected branches and envars ― how it affects PSR

Managed to make my setup commit version bump in pyproject.toml and make a git tag after MRs onto develop (protected) branch. The last piece is to make it commit updated changelog.

release:
  stage: release
  image: python:3.12
  variables:
    GITLAB_TOKEN: $AUTOMATION_ACCESS_TOKEN  # Project/Personal Access Token...
    GIT_STRATEGY: clone
    GIT_DEPTH: 0
    GITLAB_CI: true
  before_script:
    - pip install python-semantic-release
  script:
    - git fetch --tags
    - git checkout $CI_COMMIT_REF_NAME
    - semantic-release version
    - semantic-release changelog
    - git status  # Here I have CHANGELOG.md in staging...
    - semantic-release publish
  only:
    - develop

And still, sometimes I though if I should have used to-be-continuous' template.

Update on changelog: apparently, changelog updates are pushed if a new tag (or release?) is created.

I recently went through this myself. This was part of a container image build pipeline and I wanted to push that image using the version and test it before I actually published a new release. So I broke this up into templates as shown below.

.semantic_prep:
  image: ${PIPELINE_SEMVER_IMAGE}:${BUILDAH_OUTPUT_TAG}
  variables:
    GIT_STRATEGY: clone
    GIT_DEPTH: 0
    GIT_COMMIT_AUTHOR: "semantic-release <$GITLAB_USER_EMAIL>"
  before_script:
    - git config --global --add safe.directory "$CI_PROJECT_DIR"
    - git checkout -b "$CI_COMMIT_REF_NAME"
    - git status

.semantic_release_next_version:
  extends: .semantic_prep
  script:
    - echo "NEXT_VERSION = $(semantic-release version --print-tag)" >> next_version.env
  artifacts:
    untracked: false
    when: on_success
    expire_in: "30 days"
    reports:
      dotenv: next_version.env

.semantic_release:
  extends: .semantic_prep
  script:
    - semantic-release version

I reference these templates like so:

store_next_version:
  extends: .semantic_release_next_version
  stage: test
  variables:
    BUILDAH_OUTPUT_TAG: "dev-${CI_COMMIT_SHORT_SHA}"
  rules:
    - *run_on_merge_requests_and_main

semantic_release:
  extends: .semantic_release
  stage: publish
  variables:
    SEMANTIC_RELEASE_OPTIONS: "version"
    BUILDAH_OUTPUT_TAG: "dev-${CI_COMMIT_SHORT_SHA}"
  rules:
    - *run_on_main_and_web

I use this pyproject.toml in the root of the repo

[semantic_release]
allow_zero_version = false
tag_format = "v{version}"
version_variables = [
    # "file:variable:format_type"
    "version.yml:image_version:tf",                   # Tag format
]
assets = []
build_command_env = []
commit_message = "Semantic Release - Tag {version}\n\nAutomatically generated by python-semantic-release"
commit_parser = "conventional"
logging_use_named_masks = false
major_on_zero = true
no_git_verify = false


[semantic_release.branches.main]
match = "*"
prerelease_token = "rc"
prerelease = false

[semantic_release.changelog]
exclude_commit_patterns = []
mode = "init"
insertion_flag = "<!-- version list -->"
template_dir = "templates"

[semantic_release.changelog.default_templates]
changelog_file = "CHANGELOG.md"
output_format = "md"
mask_initial_release = false

[semantic_release.commit_author]
env = "SEMANTIC_RELEASE_AUTHOR"
default = "semantic-release <semantic-release>"

[semantic_release.commit_parser_options]
minor_tags = ["feat"]
patch_tags = ["fix", "perf"]
other_allowed_tags = ["build", "chore", "ci", "docs", "style", "refactor", "test"]
allowed_tags = ["feat", "fix", "perf", "build", "chore", "ci", "docs", "style", "refactor", "test"]
default_bump_level = 0
parse_squash_commits = false
ignore_merge_commits = false

[semantic_release.remote]
name = "origin"
type = "gitlab"
# Will look for env GITLAB_TOKEN when type = gitlab
# A Project Access Token should exist with permission to push/tag/release
ignore_token_for_push = false
insecure = false

[semantic_release.publish]
dist_glob_patterns = ["dist/*"]
upload_to_vcs_release = false

This publishes a tag, release and pushes the updated changelog

Update on changelog: apparently, changelog updates are pushed if a new tag (or release?) is created.

@UnoYakshi, Not sure what you meant but the logic is:

1. --changelog and --no-changelog determine if the changelog is generated or not. If you do not specify --no-changelog it is created by default.

2. Secondly, the changelog will be committed as part of the "version commit" to the local repository (ie to save the changelog for this release) by default unless the --no-commit option is provided.

3. As long as you have not specified the --no-push option then the commit will be pushed to the repository given that you have configured the repository with write permissions to the repository.

4. Tags are created by default unless the --no-tag option is provided. PSR will tag the HEAD commit which is either the new version commit (when commits are enabled) or when --no-commit is provided it will be the CI_COMMIT_SHA.

5. As long as --no-vcs-release is NOT provided, then PSR by default will create a release entry on GitLab pointing at the newly published tag and it will include the "release notes" for that version. In other words this means only the changes between the last release and the current release.

It has been 60 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?