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)

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

Every project requires an access token with write_repository which creates a new bot user every time
Group access tokens can be used to limit the number of bots mentioned above, but then security takes a hit
CI_JOB_TOKEN is better scoped and short-lived
No expiry of tokens as Gitlab limits access tokens to 1 year now

Possible implementation

python-semantic-release/semantic-release/hvcs/gitlab.py L76 reads:

self._client = gitlab.Gitlab(self.hvcs_domain.url, private_token=self.token)

CI_JOB_TOKEN requires that the client be created as such:

self._client = gitlab.Gitlab(self.hvcs_domain.url, job_token=self.token)

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.

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

feat(gitlab): add `$CI_JOB_TOKEN` support for GitLab v17.2 and greater

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?

feat(gitlab): add `$CI_JOB_TOKEN` support for GitLab v17.2 and greater

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

@a-gertner take a look here: #1098

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

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

Navigation Menu

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

Use cases

Possible implementation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Use cases

Possible implementation

Activity

codejedi365 commented on Jul 12, 2024

github-actions commented on Sep 11, 2024

codejedi365 commented on Sep 11, 2024

github-actions commented on Nov 11, 2024

codejedi365 commented on Nov 11, 2024

github-actions commented on Jan 12, 2025

svaningelgem commented on Jan 20, 2026

a-gertner commented on Feb 19, 2026

benedikt-bartscher commented on Feb 19, 2026

a-gertner commented on Feb 19, 2026

github-actions commented on May 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions