I created a Project Access Token (project_bot_1_xxxx). on project1 that I use in CI/CD to bump the version of my package. The CI/CD job uses “bump2version patch” to update some files in the repo and then git remote add gitlab_origin https://oauth2:$BUMP2VERSION_TOKEN@gitlab.example.com/xxx/yyy.git", and then git push --tags gitlab_origin HEAD:master`.
This part works, I see a new commit in the repo created pushed by this “project_bot_1_xxx” user.
Now that push will trigger a new pipeline (different jobs than the previous one) that will build and publish the python package to the package registry of project2.
project2 is just placeholder project that I want to use just to to have a single package registry to publish all python packages from other repos.
Now, the publishing from project1 to project2 does not work because I’m using $CI_JOB_TOKEN to publish (TWINE_PASSWORD=${CI_JOB_TOKEN}) and $CI_JOB_TOKEN has the permission as the user that triggered the pipeline which is project_bot_1_xxx and that is a Maintainer in project1 but it has no permission whatsoever in project2.
But the I realized that I can’t just add project_1_bot_xxx to project2 , that does seem to be allowed at all.
I know that I can create a Deploy Token on project2 and use that as CI/CD variable in project1. But I really like the idea of having a short-lived token like CI_JOB_TOKEN instead of creating a long-lived Deploy Token.
Is there any way to have a shared project bot user between two unrelated projects (they are not in the same group)? Any other idea on how to approach the problem?
Bot users are scoped to the project/group they are created in. There is currently no way to add them as members somewhere else. Only workaround is to create another Project Access Token in project2 and use that.
As an alternative you could schedule a pipeline that will do what you need. Scheduled pipelines run as the user who created the schedule. But in this case the push to project2 won’t be instantaneous and you probably need to handle any possible diffs in pushed versions.
Another alternative is to create a dedicated user with access where you need. But in case of paid sub you will pay for the seat.
1 Like
I created a Deploy Token in project2 and use it as TWINE_USERNAME/TWINE_PASSWORD in project1, but the UI experience in project2 package registry is bad:
I get “Manually published” don’t get a reference to the commit.
Now if I create a new Project Access Token in project2, and use that for TWINE_USERNAME/TWINE_PASSWORD in project1, it’s also bad, it just says “manually published”
When I use CI_JOB_TOKEN and retrigger the pipeline in project1, then the CI_JOB_TOKEN has my user permissions and when the package is published , then the package registry UI tells the tag and commit.
I think you only get this kind of UI experience with CI_JOB_TOKEN because then GitLab knows that CI_JOB_TOKEN corresponds to a specific pipeline and it knows the metadata of that particular pipeline execution. So then it’s able to embed that metadata automatically at publish time if you are using the CI_JOB_TOKEN as credentials.
But if CI_JOB_TOKEN requires project1 and project2 have a user in common and that can’t be a bot user then that’s a bummer and I’ll have to live with the ugly “Manually published”.
I have filed a proposal in GitLab to allow this use case Allow Project Access Token to have permissions in other projects via CI_JOB_TOKEN (#415362) · Issues · GitLab.org / GitLab · GitLab
