Prebuilds stop working for team projects when an owner without repo access joins the team

[jldec]

This issue is a result of investigating #7648 and #8118.

Team-project prebuilds depend on the 1st (returned from DB) team-owner's permissions. If that user does not have the right access to the repo, then the prebuilds stop working. This can start happening if another team-owner is added later, after the project has been working for a while.

findProjectOwner() is called during handlePushEvent(), and the owner is then used to do fetchConfig() which will fail silently if the owner does not have permissions, causing the prebuild not to be triggered.

Examples of these fetchConfig errors can be found in traces and trace-detail. (internal)

gitpod/components/server/ee/src/prebuilds/github-app.ts

Line 358 in 28597c5

: (await this.teamDB.findMembersByTeam(project.teamId || '')).filter(m => m.role === "owner")[0];

To reproduce

• create a team, add a project with prebuilds, confirm that prebuilds are triggered
• invite a new member to the team who does not have access to the project repo
• set the role of the new member to owner
• observe that prebuilds not being triggered as expected anymore
• remove the new owner from the team
• observe prebuilds resume

[jldec]

One suggestion for a fix from @konne is to separate the roles of admin and owner.

[jldec]

another suggestion from @jankeromnes

Thankfully, I think @AlexTugarev recently implemented a new behavior that I think we should adopt everywhere:

• If the installer of the app is (still) a member of the team, use their token (best case)
• If the team doesn't have the app's original installer anymore (left the team / deleted account / etc), fall back to any member that has a connected identity with the targeted Git host
• (If this still doesn't work, we can't do better, and should probably tell the team the integration is in a bad state / needs to be re-installed)

[konne]

@jankeromnes

The idea is great to have less friction and support for users because it will in most cases just automatically work.
The disadvantage is for me that if I look into enterprise readiness it has not a predicted usage of tokens and even sometimes in that case you want to really define which token is used for access. This is in most cases related to forbidden or limited usage tracking or fraud prevention.

The other point came into my mind. What happens if I only have one owner and this user gets blocked by Github (whatever the reason is) This lead to the situation that the team can not be managed anymore but you can also not create a new team and add the projects, because the projects are already added to that team.

[AlexTugarev]

it has not a predicted usage of tokens

@konne, given that we'll fix the selection of a user account to fetch repo installation with, I would like to understand that point of yours. If a project belongs to a team, any team member's token with necessary permissions should be good to use for prebuilds. That should solve problems with rate limitation and improve reliability.

[konne]

@AlexTugarev for example in enterprise usage of GitLab I know companies that check the usage of API tokens also per IP.
If the system just selects a random one it can be that this generates a false positive alarm.
I don't see you current in general as a problem it will work in 99,999% of customers. I just wanted to highlight that sometime admins want to have better control.