I'm still planning to write documentation for this, but I would appreciate a first feedback on the approach.
Thank you

This should resolve #663 and #666, please tell me if I'm forgetting something?

@aborsu, I appreciate you taking the initiative on this. I'll take a look more in depth tomorrow. I would rather not cause confusion between a GitLab CI and a regular GitLab as it is the intent each HVCS is to be able to be run in the CI and locally. If you can adapt the current GitLab Hvcs object that would be best.

I had the same thought to have it work with the CI_JOB_TOKEN which means we have to modify the GitLab(*_token) call accordingly. Personally I was thinking of implementing the function in python-gitlab's cli.py which will derive the correct token based on the environment which I think is what we need but also a merge between using the current configuration parsing for environment variables.

The other problem we have is the call to gl.auth(), this did not work for me with a CI_JOB_TOKEN. Were you able to get this to work?

Separately, when I tried to solve this problem previously, the tag publishing is the biggest limitation. If you run semantic-release version --push then it will try to execute git push --tags to publish the commit & or tag to the repository. The CI_JOB_TOKEN does not have enough scoped permissions for this. It can write to releases but it cannot write to the repository which is where the tags go. Secondly, I don't think you can make a vcs release without a tag to link it too. I have detailed this further in #768.

Were you able to solve these problems?

@codejedi365 I can try to bring the two together later this week.
As I wrote in my first message gl.auth() will not work with a CI_JOB_TOKEN as written in the documentation of python-gitlab api-usage.
This is because the CI_JOB_TOKEN has only access to a subset of the API, and on top of that there is no way to push using a CI_JOB_TOKEN cfr. 389060.

Using the CI_JOB_TOKEN with python-gitlab is broken as many methods do not work. At the same time all the information is available in the environment variables. Basically, I would be fine putting a choice job_token or pat_token in a single class, the difficulty is the fact that the current Gitlab class works from outside the CI, mine doesn't so that would be a breaking change.

My ideal workflow (but only works on gitlab ultimate or premium), is that we have a Project Access Token as a guest on the project with a token that only allows it to push to master. It cannot use the API, it cannot push to another branch.
We use those credentials to push the commit and tag.

We then use the CI_JOB_TOKEN to create the release in HVCS.

I added the following doc

Using a Job Token

In order to use gitlab-ci job token you need to configure python semantic release by adding the following to your
pyproject.toml file:

    [tool.semantic_release]
    remote.type = "gitlab-ci"
    remote.ignore_token_for_push = "true"

The following workflow is proposed to the reader.

A Project Access Token is created in Gitlab and given the right to push to the main branch.
This token is added as a secret variable in your Gitlab CI project under the name GL_PROJECT_TOKEN_NAME and
GL_PROJECT_TOKEN. This token should only have write access to the repository, it does not require API access.
If you are using Gitlab Premium or Ultimate, you can make this token a guest to further restrain the token's scope,
and specify it as the sole person allowed to push to the master branch.
Otherwise, you will have to grant that project access token a sufficiently high access privilege that it can push to
the main branch.

The following .gitlab-ci.yml should be enough to get you started:

    stages:
      - publish # Deploy new version of package to registry
    # Official language image. Look for the different tagged releases at:
    # https://hub.docker.com/r/library/python/tags/
    image: python:latest
    variables:
      PIP_CACHE_DIR: $CI_PROJECT_DIR/.cache/pip # Set folder in working dir for cache
    # Runs on commit in main branch that were not made by the semantic-release job
    # Using GITLAB_USER_EMAIL in the GIT_COMMIT_AUTHOR will display the person who
    # triggered the job either by clicking the merge button or pushing to master
    # as the author of the commit.
    version_and_publish:
      stage: publish
      image: python:latest
      variables:
        GIT_DEPTH: 0
        GIT_COMMIT_AUTHOR: "$GL_PROJECT_TOKEN_NAME <$GITLAB_USER_EMAIL>"
      before_script:
        - pip install python-semantic-release
        - pip install twine
      script:
        - git checkout "$CI_COMMIT_REF_NAME"
        - git remote set-url origin https://${GL_PROJECT_TOKEN_NAME}:${GL_PROJECT_TOKEN}@${CI_REPOSITORY_URL#*@}
        - semantic-release version
        - |
          if [ "dist" ]; then
            TWINE_PASSWORD=${CI_JOB_TOKEN} TWINE_USERNAME=gitlab-ci-token python -m twine upload --repository-url ${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/pypi dist/*
          fi
      cache:
        paths:
          - ${PIP_CACHE_DIR}
      rules:
        # Don't run on automatic commits
        - if: $CI_COMMIT_AUTHOR =~ /$GL_PROJECT_TOKEN_NAME.*/
          when: never
        # Only run on main/master branch
        - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

I'm very interested in this PR. Does it also imply that a PAT doesn't actually work here? I've been grinding my face on the keyboard all week trying to figure out how to set up auth for Gitlab.

Does it also imply that a PAT doesn't actually work here?

@sbates No, a Personal, Group or Project Access Token will work if your token permissions are correct.

It is the CI_JOB_TOKEN that does not work inherently due to the pushing of commits and/or tags. CI_JOB_TOKEN's have restricted api endpoint permissions that are not modifiable and unfortunately the ability to write to the remote git repository is not one of them.

Writing to the repository is one such permission that PSR requires.

This PR is stale because it has not been confirmed or planned by the maintainers and had been open 60 days with no recent activity. It will be closed in 10 days,
if no further activity occurs. Thank you for your contributions.

This PR was closed because activity was dormant for 70 days.

Hello,

Is it possible to re-open this PR, and maybe add the confirmed label to prevent GitHub Actions from closing it again?

It's true that it is currently stale as some changes were requested (not having a new provider), but I believe that closing a PR with a good start doesn't help getting progress on the feature.

Thank you 😃

@Exagone313, although I see your point, I don't agree with your solution. My issue is that PRs are restricted to the owner whom opened them and the maintainers. So even if a new contributor came along to complete it they would open a new PR. Even having a new contributor come along is unfortunately very unlikely based on my experience. But if they did and they wanted to use the code, they still can from a closed PR by using git fetch. It is closed because it's not going to be merged from its current state. And as time goes on the head of this branch diverges more and more from the current state of the project, which is more complicated to integrate over time.

In this specific PR, There are current issues that indicate this is still a feature request, so it is not forgotten. I have been monitoring this PR as I still value GitLab usage but I've been working other more significant efforts. Until recently job tokens were not possible as I stated above but luckily changed as identified in #977. I have extracted what code is valuable from this PR and kept it updated on my own branch. But given my feedback previously I can't say this is the code someone else should start with.

But all in all, a PR will be closed if it is not being worked, as it dilutes priorities of all the other progress of the project (remaining issues + PRs).