Rewrite Default CI/CD job token (CI_JOB_TOKEN) scope changed deprecation notice & related issues
Context / Problem
Over the past few weeks there has been a bit of confusion about https://docs.gitlab.com/ee/update/deprecations.html#default-cicd-job-token-ci_job_token-scope-changed and what it will mean to existing projects in the GitLab ecosystem:
- https://gitlab.slack.com/archives/C0276KTHJUX/p1681508030544759 - Customer question
- gitlab-com/gl-infra/delivery#2951 (comment 1348005767) - Delivery Group confusion (now updated for 17.0)
- gitlab-org/gitlab#395708 (comment 1354625203) - Inconsistencies in inbound/outbound
I think we are missing an example that could make the customers feel more comfortable with the situation. It seems that the existing language needs double checking in a couple of places to make sure it's accurate and free of typos.
Proposal
- We update the language to be clear about exactly what impact there will be to existing projects, including the implication of updating the settings to projects and not being able to change them back.
- Update the associated issues language and description to be consistent
- We add the GitLab repository as a worked example to the deprecation notice so that customers have a public example to double check (if they wish).
Suggested format:
Existing Deprecation
This deprecation ...
...
How to assess for Impact
Existing projects have no impact, only projects created after ........
N.B. If the project settings are updated to use the inbound token, you will not be able to go back to the outbound token
How to adjust/remediate
You can start using the inbound token for projects ....
N.B. Do not update the settings on projects you will continue to need the outbound token on. If the project settings are updated to use the inbound token, you will not be able to go back to the outbound token