We have been following the upgrade path in order to get an ancient gitlab-ce instance running v12 up to date. We’ve managed to update the instance to v16.7.10 without issue but have now hit a snag where maintainers can no longer run pipelines even though they are allowed to according to the repository > protected branches settings.
Even stranger is that on some projects in the same group the behavior seems to differ even between users with the same role.
| Pipeline allowed to run? |
User X (owner) |
User Y (maintainer) |
User Z (maintainer) |
| Project A |
Yes |
No |
No |
| Project B |
Yes |
Yes |
No |
I’ve been bashing my head against this issue for a few days now so any advice would be much appreciated.
Steps to reproduce
We’ve tried inviting users with maintainer role directly to the project, instead of inheriting the role via the group setting as well as changing the permission via the api. Users still see ‘You do not have sufficient permission to run a pipeline on ‘master’ when trying to run the pipleline.
Configuration
Version:
- GitLab Community Edition v16.7.10
- Running on Docker
Hi,
Firstly, it’s going to be very hard to give you support, since v16 is still 2 major versions behind the actual supported version.
Secondly - have you followed upgrade path exactly as in the docs, and waited for all the background migrations to finish? This sounds to me, like some data hasn’t been properly migrated.
Thirdly - are your Runners also up-to-date, matching with GitLab server version in Major.Minor?
Thanks for the reply.
I realise we’re still behind the oldest still supported version. Yes we’ve been following the recommended upgrade path step by step as defined here: Upgrade Path.
All background migrations have completed successfully.
We’ve noticed that users in certain groups don’t experience this issue but the same users can’t run pipelines in other groups even though the settings seem to be identical on the groups/repos.
This afternoon we removed users from the affected groups and re-added them and this seems to have solved the issue. As the behaviour was inconsistent between users I’m not quite ready to say it’s solved across the board by removing and then re-adding the users to the groups but the first signs are encouraging at least.
For whatever reason, removing and then re-adding the users to the groups fixed the issue.
