“No permissions to trigger downstream pipeline” … for a user who has permissions

I ran into what appears to be a bug with a GitLab 13.8.4 Premium setup. This project has a number of repositories (one per service) and a combined deployment job for the ones which are not yet containerized.

The layout looks like this, with a number of internal projects:

• app deployment: Ansible job which deploys onto the appropriate servers
• service1
• service2
• service3
• regression-tests

Each of the services has protected branches which trigger app deployment for the same branch to deploy to the appropriate protected environment. This is implemented with trigger: on the app deployment repo. The app deployment repo has a trigger: block which runs the regression test suite.

For me (with admin permissions) this all worked. This morning a user got an error “trigger_regression_tests - failed - (no permissions to trigger downstream pipeline)” on the same pipeline I’d tested (service1 triggered app deployment successfully, app deployment got that error triggering regression tests). At first, I thought he just didn’t have permissions to merge to that branch but then I checked that he did and I impersonated him long enough to confirm that he had permissions to trigger the same pipelines on the same branches in the same projects.

This hits a larger topic of the permissions model being somewhat complicated when not everyone has full access to everything. We frequently hit situations where it’d be nice to say “user X can trigger pipelines on branch Y but not otherwise have much access to this project” and subscriptions can’t really be used since they require projects to be public and only support the default branch. I can use curl with a token, of course, but then I have to manage another secret and the UI isn’t as nice. I created Allow cross-project triggers for users without permissions (#276706) · Issues · GitLab.org / GitLab · GitLab 3 months ago for a separate reason but this would be another area where something like that would be useful both for improving security and making the relationships more obvious.

I reported this as “No permissions to trigger downstream pipeline” … for a user who has permissions (#326941) · Issues · GitLab.org / GitLab · GitLab since a supported feature doesn’t work and there’s no good workaround which doesn’t add maintenance overhead or remove functionality (e.g. tokens can trigger builds but break the feedback UI)

I too find the permission model lacking. I would like to have projects where the permission to run the pipelines is separate from the permissions to edit the code. We have deployment projects which are to be run as downstream pipelines from the application projects. We do not want to give the developers fo the other projects permission to modify the code, but we do want to give them permission to run the pipelines. We have tried the api method to trigger the jobs using project keys and we can make it work. But now the visualization which is so powerful is not available. Moreover we want to manage the permission to deploy to production from the initiating project not from this downstream project. I wish the “trigger” operation had more capabilities - to be able to set the environment property to be able to run a before script and after script so the calling application could debug parameter settings and handle the return value. and most of all I’d like to be able to pass the a project key, similar to the api calls.