Have a GitLab self-managed instance with a group containing multiple private projects. For repositories that depend on each other for a build, typically the approach used in a CI job was to clone a repository in a before_script using an ephemeral token (CI_JOB_TOKEN) as outlined in “Use a job token to clone a private project’s repository”:
You can use the job token to authenticate and clone a repository from a private project in a CI/CD job. For example:
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>
When trying this approach with newly created projects in an updated GitLab, clones appear to fail. Inspecting the repository setup, this appears to be related to a recent GitLab change which default-enables a (new) option called “Limit access to this project”. It appears that with this option enabled and permission granted to each project that depends on a given project, these clones will work.
However, this now creates a lot of maintenance work. Having to give explicit access for each project wanting to clone a repository is a lot of maintenance work (e.g. if 50 projects depend on a common project, the common project needs to give permission for each repository). I assume why the new restrictions exist is that CI_JOB_TOKEN can do more than just read a repository (especially if a pipeline is triggered from a user with more privileges). If CI_JOB_TOKEN can no longer be used, is there an alternative job-specific token that can clone private repositories?
A workaround for this is to setup a new access token on the group that has a read_repository scope, add the token as a CI variable for the group and then update all git clone usages in jobs to use this new token. This is less than ideal since the token’s life cycle is no longer tied to a job, but I am not sure of any other way to approach this.
Any recommendations are appreciated.