René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"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)","articleBody":"## Description\r\n\r\nCurrently, 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.\r\n\r\n[Allow CI_JOB_TOKEN to push to its own repository #389060](https://gitlab.com/gitlab-org/gitlab/-/issues/389060)\r\n\r\n## Use cases\r\n\r\n* Every project requires an access token with write_repository which creates a new bot user every time\r\n* Group access tokens can be used to limit the number of bots mentioned above, but then security takes a hit\r\n* CI_JOB_TOKEN is better scoped and short-lived\r\n* No expiry of tokens as Gitlab limits access tokens to 1 year now \r\n\r\n## Possible implementation\r\n\r\npython-semantic-release/semantic-release/hvcs/gitlab.py L76 reads:\r\n``` python\r\nself._client = gitlab.Gitlab(self.hvcs_domain.url, private_token=self.token)\r\n```\r\n\r\nCI_JOB_TOKEN requires that the client be created as such:\r\n\r\n``` python\r\nself._client = gitlab.Gitlab(self.hvcs_domain.url, job_token=self.token)\r\n```\r\n\r\nMaybe 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.","author":{"url":"https://github.com/fcinqmars","@type":"Person","name":"fcinqmars"},"datePublished":"2024-07-11T19:30:48.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/977/python-semantic-release/issues/977"}