Implement $CI_JOB_TOKEN support in releases #1098
Conversation
eaef8ca to
d6ce55c
Compare
|
@KundaPanda, this is a great contribution as you also included tests and documentation, Thank you! I just want to add a few things and we will get this merged in and released. |
|
Any update on this? From the comments it seemed pretty ready for merge |
|
I'll take a look at it again this weekend. It got majorly complicated because it was a bit premature to add this functionality without handling all the variations of GitLab installations. After digging through GitLab's issue queue, I found that the CI_JOB_TOKEN support was only provided behind a feature flag that was turned off by default. Then I found that the official GitLab (gitlab.com) did not activate this feature flag because of a secondary issue ticket of infinite looping pipelines. This added undo complexity to attempting to determine what error states could happen. The goal was to support GitLab proper, GitLab on-prem of multiple versions (no feature flag, feature flag disabled, and feature flag enabled). Each circumstance would provide some level of error message to the user of why it's not working otherwise I get a lot of issue tickets about why it isn't working. |
|
Hi @codejedi365 thanks for trying to implement this properly and support all deployment variants. If you need any testing, we could test this on our gitlab instance or even provide you with a token/user to test it yourself.
Can you refer to those issues/feature flags? In general, CI_JOB_TOKEN should be available in all environments afaik. Is it a specific permission which is missing? |
Wow, why thank you. I'll let you know if I need a testing environment. I do have a separate GitLab instance to test against when I get to that part but I appreciate the gesture.
The job token has been available for a long time, but the problem has been permissions. It was restricted from writing to the repository. It has specific permissions hardcoded by GitLab. This is unlike GitHub which enabled users to define the permissions of the token per workflow or job. In GitLab v17.2 (see #977), it was provided as a feature flag that admins could enable but it was disabled by default. GitLab.com does not expose feature flag enablement to users and so it is disabled. Original: https://gitlab.com/gitlab-org/gitlab/-/issues/389060 Oddly enough even as this permission becomes available, previously you could write to the releases endpoint via the API and it will create the associated tag at a given commit sha. The problem is that PSR was not written to support this by the original maintainers. In this circumstance, you also must point the release at an existing commit in the remote which would require |
|
It has been 60 days since the last update on this confirmed PR. @python-semantic-release/team can you provide an update on the status of this PR? |
Purpose
Implement support for the
CI_JOB_TOKENvariable in Gitlab CI.CI_JOB_TOKENs can now be used to push to repositories, and using them is both safer and easier.Rationale
The
CI_JOB_TOKENshould only complement the usage ofGITLAB_TOKENand respect its' value when used. When the values ofGITLAB_TOKENandCI_JOB_TOKENmatch, or the remote token env name is set toCI_JOB_TOKEN, it is considered to be a job token. WhenGITLAB_TOKENis not specified, theCI_JOB_TOKEN's valu 8000 e is used.How did you test?
I added some parameters to the existing GitLab unit test that checks the usage of the environment variable. I also created an e2e test case that checks various combinations of personal token and job token usage in requests to the GitLab API.
How to Verify
tool.semantic_release.remote.tokento{ env = "CI_JOB_TOKEN" }or assignexport GITLAB_TOKEN = $CI_JOB_TOKENin a GitLab CI configuration.