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 until https://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.