A bit of a goofy behavior, but Gitlab's CI_JOB_TOKEN (the access token created for the execution of each CI job), has very selective access to the Gitlab API.
Errors using install_gitlab in private gitlab CI
Notably, it does not have access to the projects/:id/repository/files endpoint or projects/:id/repository/archive endpoint used to fetch the remote DESCRIPTION and download the package archive. These are accessible on public Gitlab because these endpoints are accessible without authentication. However, any private instance which requires authentication will fail using this token. Users would have to embed personal tokens with a CI job in order to use install_gitlab - feasible, but a poor practice as personal tokens would be exposed to co-maintainers/owners.
Oddly enough, the CI_JOB_TOKENdoes have full ability to git clone any unrestricted private repo using basic auth (git clone https://gitlab-ci-token:$CI_JOB_TOKEN@example.com/<namespace>/<project>.git). This can be used in any CI job after setting
When the projects/:id/repository/files endpoint returns a 401 response, it would be wonderful if remotes would fall back to using install_git in its place. This would allow use of install_gitlab within CI jobs without having to embed personal access tokens within the repo's env vars.
PR Considerations
I'd be happy to help put together a PR, but I would appreciate some feedback about approach. As is, the first failed request isn't hit until remote_package_name, but I don't think that's the right point to handle the fallback. Alternatively, this endpoint could get hit even before returning a remote object from install_gitlab, allowing an easy point to fallback, but possibly duplicating a request.
If you'd be interested in accepting this functionality, I would greatly appreciate some thoughts on the design before starting to put something together.
A bit of a goofy behavior, but Gitlab's
CI_JOB_TOKEN(the access token created for the execution of each CI job), has very selective access to the Gitlab API.Errors using
install_gitlabin private gitlab CINotably, it does not have access to the
projects/:id/repository/filesendpoint orprojects/:id/repository/archiveendpoint used to fetch the remoteDESCRIPTIONand download the package archive. These are accessible on public Gitlab because these endpoints are accessible without authentication. However, any private instance which requires authentication will fail using this token. Users would have to embed personal tokens with a CI job in order to useinstall_gitlab- feasible, but a poor practice as personal tokens would be exposed to co-maintainers/owners.Oddly enough, the
CI_JOB_TOKENdoes have full ability togit cloneany unrestricted private repo using basic auth (git clone https://gitlab-ci-token:$CI_JOB_TOKEN@example.com/<namespace>/<project>.git). This can be used in any CI job after settingSuggested fallback
When the
projects/:id/repository/filesendpoint returns a401response, it would be wonderful ifremoteswould fall back to usinginstall_gitin its place. This would allow use ofinstall_gitlabwithin CI jobs without having to embed personal access tokens within the repo's env vars.PR Considerations
I'd be happy to help put together a PR, but I would appreciate some feedback about approach. As is, the first failed request isn't hit until
remote_package_name, but I don't think that's the right point to handle the fallback. Alternatively, this endpoint could get hit even before returning aremoteobject frominstall_gitlab, allowing an easy point to fallback, but possibly duplicating a request.If you'd be interested in accepting this functionality, I would greatly appreciate some thoughts on the design before starting to put something together.