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

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.

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?

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.

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.

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?

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
Roll-out plan:https://gitlab.com/gitlab-org/gitlab/-/issues/468320
Which then Scott Hampton mentions, it can't roll out untilhttps://gitlab.com/gitlab-org/gitlab/-/issues/475705

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--no-commit to be set on PSR. Consequently how do we handle an updating changelog because we can't commit it with each release. I bring this up because GitLab has this issue but so does GitHub if you choose to add additional protections to your default branch. I feel we are in a no-win solution currently for better security and automated releases. Not to mention the importance of limiting subsequent pipelines via GitLab's workflow rules and GitHub's action event triggers which I get too many issues reported about. I digress.

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?

It seems like there is some movement on gitlab's side. They are currently rolling out the feature flag in production... Let's hope everything goes well and we can finally have secure granular permissions without configuration overhead 🙏

Gitlab has rolled out the feature on almost all deployments - GA is planned for the next feature release 18.4 (https://gitlab.com/gitlab-org/gitlab/-/issues/468320#note_2679031928). 18.4 should be released in about 2 weeks.

Hopefully we can finally get this one in. If you need any help/testing, feel free to ping me

Thanks for the update! I should be able to work on this after finishing the monorepo parser PR.