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.