Open
Description
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.