Repository navigation
Support CI_JOB_TOKEN now that Gitlab added the option for it to push to its own repository which will be released in 17.2 (July 18th) #977
Description
Activity
Thank you for submitting this ticket. It is great news to hear that push will now be available for GitLab and I wouldn't have been tracking that improvement without your submission.
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 had some work towards this but got sidetracked with other improvements, hopefully circle back around to this soon.
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?
Still in backlog
- linked a pull request that will close this issueImplement $CI_JOB_TOKEN support in releases #1098
on Nov 16, 2024 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?
- added a commit that references this issue
on Jan 12, 2025 - added a commit that references this issue
on Jan 26, 2025 - added a commit that references this issue
on Feb 6, 2025 - added a commit that references this issue
on Sep 14, 2025 Hello, is there any information regarding this PR? We would love to start using the CI-token on gitlab if at all possible.
Hi, just joining this discussion after #1431 was closed as a duplicate.
May I ask what is maintainers view on this topic?- Useful and will imeplemt?
- Useful but not a priority?
- Won't implement because ...
I am not the best python dev in the world, but I am happy to invest some time and contribute to PR if needed.
@a-gertner take a look here: #1098
Reacted by A. Gertner@a-gertner take a look here: #1098
Ah, thanks. My bad, I did not notice that PR already exists.
Had a quick look through the diff, it looks great. Different from implementation I had in mind, but very good nevertheless.My original idea was to not implicitly get CI_JOB_TOKEN from ENV var, but rather handle a special case where user specifies it in semantic-release config:
[semantic_release.remote] type = "gitlab" token = {"env" = "CI_JOB_TOKEN" } # this will be treated as job_token
[semantic_release.remote] type = "gitlab" token = {"env" = "ANY_OTHER_TOKEN_NAME" } # this will be treated as private token
But I guess I am late to the party with my ideas. @KundaPanda's solution is great.
Thanks a lot for great features!
Reacted by benedikt-bartscher and Antonio Huete JimenezIt has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Description
Currently, semantic-release expects an Access Token to be used with Gitlab because the CI_JOB_TOKEN would not allow pushing to the repository. Now that Gitlab has enabled that, it would nice to leverage the CI_JOB_TOKEN instead of having to manage expiring tokens per project or group.
Allow CI_JOB_TOKEN to push to its own repository #389060
Use cases
Possible implementation
python-semantic-release/semantic-release/hvcs/gitlab.py L76 reads:
CI_JOB_TOKEN requires that the client be created as such:
Maybe we could add an extra parameter or check if CI_JOB_TOKEN exists when the environment variable GITLAB_TOKEN is not populated in order to determine which of the two syntax to use.