Skip to content
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] store separate email used for commits (GitHub and GitLab) #4115

Merged
merged 2 commits into from
Jul 8, 2021

Conversation

philschatz
Copy link
Contributor

GitLab and GitHub both have a way to specify an email address for commits that is different than the primary email used for a user account.

GitLab contains a field for the commit email and while GitHub does not provide a similar field in their API, their Desktop client constructs this email address

🤞 😅 that this works.

Fixes #387, #2007, #3186, #4101

@AlexTugarev AlexTugarev self-requested a review May 4, 2021 05:34
@AlexTugarev
Copy link
Member

AlexTugarev commented May 4, 2021

/werft run

👍 started the job as gitpod-build-ps-commit-email-fork.0

@philschatz
Copy link
Contributor Author

Thank you for the suggestions! I updated the PR with them but had trouble connecting to https://ps-commit-email-fork.staging.gitpod-dev.com/workspaces/ to see if it works. Is there something I can set up?

@AlexTugarev
Copy link
Member

AlexTugarev commented May 6, 2021

/werft run

👍 started the job as gitpod-build-ps-commit-email-fork.1

@AlexTugarev
Copy link
Member

AlexTugarev commented May 6, 2021

@philschatz, thanks for the update. I've triggered a a new build on werft. Our public werft is only listening to GItpod devs. I keep an eye open on the PR to trigger it, but if you won't see a new update timely, feel free to ping me 🙏🏻

@AlexTugarev
Copy link
Member

@philschatz, we forgot to add a db migration.

I'm happy to add this to this PR. Just, internally we've a discussion on how to add columns to db tables like d_b_identity. 'Keep you posted.

@philschatz
Copy link
Contributor Author

Hello @AlexTugarev 👋 . Is there any decision on how to do the db migration?

@AlexTugarev
Copy link
Member

Hi @philschatz! Sorry for the delay.
A nice option would be to introduce Identity.emails: { address:string, type: string }. As we need to be careful to not introduce expensive blocking DB migration on the production environment, it would be great to rename d_b_identity.tokens in a migration and reuse it, because this isn't in use anymore.
I'll try to make a PR against yours.

@corneliusludmann
Copy link
Contributor

corneliusludmann commented Jun 23, 2021

Hi @philschatz!

Sorry, that it took so long to get feedback. We need to get better at this.

I would like to get your great contribution into the June release which will be deployed by the end of this month. I rebased your contribution and added the proposed changes from Alex in this branch (→ diff).

We have now 2 options:

  1. We could use my branch with your commits and I'll create a PR on behalf of both of us. In that case, no action is required on your end.
  2. You could update your PR with the changes in my PR.

Your call!

After that, I'll take care that we get a review soon.

What do you think?

@corneliusludmann
Copy link
Contributor

There is one more thing, @philschatz: For legal reasons, we need a signed contributor license agreement (CLA) from each contributor. @meysholdt will get back to you on this.

@philschatz
Copy link
Contributor Author

Hello @corneliusludmann ! I somehow missed your comment on options but did sign the CLA and rebased this Pull Request with your commits.

Please let me know if there is anything else you need to get this merged (yay!)

@corneliusludmann
Copy link
Contributor

Awesome! Thanks a lot!

@AlexTugarev Do you have time to review this PR? Since I've contributed as well I need a second pair of eyes.

@@ -65,6 +65,7 @@ export interface AuthUser {
readonly authId: string;
readonly authName: string;
readonly primaryEmail: string;
readonly additionalEmails?: { address: string, type: string }[];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: could be typed as Email as well, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Yep! I believe this is now resolved.

@@ -98,26 +98,35 @@ export class GitHubAuthProvider extends GenericAuthProvider {
.map((s: string) => s.trim())
);

const filterPrimaryEmail = (emails: typeof userEmails) => {
const blockPassListEmail = ((emails: typeof userEmails) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be moved to UserService.handleNewUser, cf. https://github.com/gitpod-io/gitpod/blob/main/components/server/src/user/user-service.ts#L140
This way, we do not need to repeat filtering.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we store all verified emails (as suggested below) we can drop this here because it is already in UserService.handleNewUser. See:

https://github.com/philschatz/gitpod/blob/88af0c51bf7c29b55e510c24d7c825aaa28b3254/components/server/src/user/user-service.ts#L143-L144

Otherwise, this filter would be necessary to store just the needed email addresses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 I believe this is now resolved.


return <AuthUserSetup>{
authUser: {
authId: String(id),
authName: login,
avatarUrl: avatar_url,
name,
primaryEmail: filterPrimaryEmail(userEmails)
primaryEmail: primary.email,
additionalEmails,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add all verified email addresses to additionalEmails here. This could also be of use to improve the signup process.

The proxy is marked as type=commit, which is also available in the GitLab case. 👍🏻

For the git config we would use identity.additionalEmails.find(isCommitEmail) || identity.primaryEmail then.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, then I would suggest adding all verified and non-private (public) email addresses.

The commit email gets the type commit (as it is now) and all others get the type other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 All verified, non-private, and non-primary emails should now be in the additionalEmails array.

CHANGELOG.md Outdated
@@ -4,6 +4,7 @@ All notable changes to this project will be documented in this file.

## June 2021

- Support custom commit email address for GitHub and GitLab (keep emai private). Thanks to [@philschatz](https://github.com/philschatz) for the contribution! ([#4115](https://github.com/gitpod-io/gitpod/pull/4115))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: typo

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also: Since we don't get this into June release, we should move this to July.

@@ -323,6 +320,21 @@ export namespace Identity {
}
}

export interface Email {
address: string;
type: string;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely should make type typesafe by having a export type EmailType = "commit" | "block_pass" (or similar).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 type is now COMMIT | OTHER since the block_pass logic is handled in user-service.ts.

@corneliusludmann
Copy link
Contributor

Thanks, Alex and Gero for the feedback.

@philschatz Please let me know if I should prepare a commit with the suggested changes (I would be happy to do so) or if you would like to do this. Your call! 🙂

@philschatz philschatz requested a review from a team as a code owner July 6, 2021 04:25
@philschatz philschatz requested a review from a team July 6, 2021 04:25
@corneliusludmann corneliusludmann removed request for a team July 6, 2021 09:48
@corneliusludmann
Copy link
Contributor

corneliusludmann commented Jul 6, 2021

/werft run

👍 started the job as gitpod-build-ps-commit-email-fork.2

@corneliusludmann
Copy link
Contributor

Hi @philschatz! Thanks for updating this PR. We are almost there! 🚀

I reviewed and tested your changes: It looks great! Unfortunately, this branch does not build because we need to rebase it on top of main and it has also merge conflicts. The good news is: I already did it in this branch and it works pretty well. I also took the liberty to squash your commits into one to have a cleaner git history.

Feel free to take the branch clu/commit-email for this PR and we are just a click away from merging this into main and getting this in production soon.

Thanks again for taking the initiative to contribute to this change and thanks for your patience. I really looking forward to having this great feature in production!

Copy link
Contributor

@corneliusludmann corneliusludmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks to you, @philschatz, we finally have this frequently requested feature in Gitpod! 🥳

@corneliusludmann corneliusludmann merged commit 1e78c6c into gitpod-io:main Jul 8, 2021
@AlexTugarev
Copy link
Member

AlexTugarev commented Jul 8, 2021

🎉 Let's verify on staging that the migration and transformation works 👍🏻

Thanks @corneliusludmann and @philschatz!

@philschatz
Copy link
Contributor Author

Thanks everyone for the help and feedback!

Also, I'm excited to try deploying 0.9.0 on my little k3s at home and being able to edit & test more contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support "Keep my email address private"
4 participants