Environment
- SonarQube Cloud organization:
[org-name](Team plan) - Login method: “Log in with GitHub”
- GitHub setup: GitHub Enterprise Cloud with Enterprise Managed Users (EMU)
- GitHub username:
jrojas_iltg(follows the standard EMU format@IDP-USERNAME_SHORT-CODE)
Issue description
After logging into SonarQube Cloud with my GitHub (EMU) account, I get the following banner and cannot use SonarQube Cloud functions:
“Your email address has not been verified. You must verify it on GitHub to access SonarQube Cloud functions.”
On the SonarQube Cloud “My account” page, my Login is shown as a synthetic placeholder address: jrojas_iltg-4KkvW@github, and this is the address being flagged as unverified.
However, on the GitHub side, my actual email jrojas@[company-domain].com is set as Primary and Verified (it is provisioned and managed by our external Identity Provider via SCIM, as is standard for EMU accounts).
It appears that at the time SonarQube Cloud first created my account via GitHub OAuth, it could not retrieve my real verified email from GitHub’s API, so it generated the placeholder jrojas_iltg-4KkvW@github instead. Now that my real email is verified on GitHub, SonarQube Cloud is still checking against that old placeholder, which can never be verified since it isn’t a real mailbox.
I found a very similar case already resolved in this community: “Cannot login to SonarCloud due to email mismatch with GitHub EMU account”, where SonarSource staff (Matthew Elliott) resolved it by manually updating the user’s email on Sonar’s side, since GitHub EMU accounts don’t support adding/mixing multiple email addresses to work around this on our end.
Request
What is the correct procedure to resolve this? Is there any self-service way to refresh/re-sync the email SonarQube Cloud has on record with what GitHub now returns, or does this always require a SonarSource staff member to update it manually on your end, as in the linked case?
Additional context
We are migrating our organization’s login method from Bitbucket to GitHub, and we expect other users in our GitHub Enterprise (EMU) to hit this same issue. If there is a process or self-service step we should follow (or point our other users to) before escalating each one individually, please let us know — that would help a lot during the rollout.
