-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[server][github] fix selection of user for prebuilds #8132
Conversation
Codecov Report
@@ Coverage Diff @@
## main #8132 +/- ##
===========================================
- Coverage 27.92% 10.82% -17.10%
===========================================
Files 41 18 -23
Lines 3510 1025 -2485
===========================================
- Hits 980 111 -869
+ Misses 2475 912 -1563
+ Partials 55 2 -53
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
const owner = installationId && (await this.findProjectOwner(cloneURL) || (await this.findInstallationOwner(installationId))); | ||
if (!owner) { | ||
log.info(`Did not find user for installation. Probably an incomplete app installation.`, { repo: ctx.payload.repository, installationId }); | ||
const installationOwner = installationId ? await this.findInstallationOwner(installationId) : undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the DB and it seems like we don't have completed installations anymore with projects. So this would not return a user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point! checking...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There seem to be a couple of installations per day:
SELECT *
FROM d_b_app_installation AS ai
WHERE ai.state = 'installed'
ORDER by ai.creationTime DESC
LIMIT 200;
So I'd expect this to work as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a lot of entry in claimed.platform
state, which mark uncomplete registrations. I don't think that is problem; except that we might want to think hope to increase conversion (out of scope here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current code will happily do prebuilds for those incomplete registrations. With this change all of them will silently no longer see prebuilds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@svenefftinge, thanks for revealing this! it's indeed a bigger issue. now that we're not encouraging users to install the Gitpod app from the GitHub marketplace, but rather go through /new
there is need to adjust the "find app installer" logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a change which alters findInstallation
in a way that can be used as intended in this PR, i.e. it will return the latest recorded installation (with a state != uninstalled) which allows to find the installer of a particular app installation. given that we should be able to fix the wrong user account selection.
For completeness, that still isn't our final destination. We want to select any team {member, owner} with proper access to that repository to be able to ready repository details necessary to create a prebuild.
The installations db is based on getting two way connection. One from GH one from gitpod and only if the two entries exist we will add a third 'installed' entry. It seems like with the new project flow we usually only get one of the signals but not the other. |
/** | ||
* Finds the relevant user account to create a prebuild with. | ||
* | ||
* First it tries to find the installer of the GitHub App installation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the logic here. But will double check with Svens comment above...
/lgtm /hold |
Thanks for working on this @AlexTugarev My main worry with the implementation is that we are still failing silently when something is not right during the prebuild handler e.g. when fetchConfig throws for some reason. Do you think we could log such errors (in addition to tracing like we do now) and include the project/repo/branch/commit context of the push notification. Logging would allow us to capture metrics also. For the future, we should also report webhook errors back to users e.g. via the dashboard or commit status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested this on a preview environment with the GitHub app installed.
Unfortunately the behavior described in #8128 is not fixed, in fact it seems worse.
Prebuilds now stop working as soon as another member who does not have repo access joins the team. The member does not have to be promoted to owner.
return finishedInstallation; | ||
} | ||
|
||
// maybe we need to finish an existing/ongoing installation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I'd love to have some reference here as it's the only piece of code that makes the table schema understandable.
Alternatively, an issue for cleaning it/the whole registration process up would be nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍🏻
@AlexTugarev New code LGTM 👍 Waiting for @jldec to approve as well. |
I have verified that for projects under a team, adding additional team members or owners who do not have access to the project repo, does not block prebuilds for that repo as reported in #8128. I see a new problem with prebuilds when the project is NOT under a team, but lives under a personal account. In that case no prebuilds happen for projects for repos from an org. (Personal repos are ok). I verified that the app was installed on the org in question. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comment - doesn't work for projects under personal accounts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
to return any non-uninstalled record which may now be used to identify the installer of an GitHub App installation.
49758c6
to
c8ef534
Compare
Just squashed the commits and need a new approval, please! |
/unhold |
Description
Related to #8093 this PR fixes a bug in the selection of the user account to ran a prebuild.
Before it would select any of the team owners.
Now it should first try with the GitHub App installer first as long as that user is still member of the team. Just as a fallback it might try to pick a team member with a github.com connection, perhaps this account has permissions to access the repository.
Related Issue(s)
Fixes #8128
Release Notes