Problem Description

Currently, when a GitHub user logs in, the system attempts to match them by their unique GitHub OAuth ID and, as a backup, by email. This approach causes an issue for pre-created users in CI/CD (GitHub actions) with only a GitHub username and no associated email address. As a result, the system creates a duplicate user with a modified username (<username>-<suffix>) instead of updating the existing user.

This workflow disrupts scenarios where a user is pre-created in the database with a specific role (e.g., admin) and needs to retain that role on the first login but lacks an email to match. Since GitHub actions provide the username (${{ github.actor }}) but do not expose the user email, this results in unnecessary user duplication.

Desired Solution

• Update the GitHub login matching logic to include theusername as a fallback when neither OAuth ID nor email match is available.
  • Order of matching:
    1. GitHub OAuth ID
    2. Email
    3. Username (new fallback option)

This will also let us make the--email flag optional incoder users create.

• Add unit tests to confirm that pre-created users with matching usernames are recognized upon login and their details are updated (e.g., email from GitHub) without creating a duplicate user.
• Ensure that no existing workflows are disrupted by adding username matching as a fallback. (regression testing)

Context

• This improvement will preserve pre-configured roles (e.g., admin) set for users in automation workflows.
• There is minimal use for this matching strategy beyond pre-created users, so the change is expected to be low-impact but useful for automation setups.

This solution will improve consistency and reduce administrative overhead by ensuring GitHub users are correctly matched based on the available information.

Bonus

Can we also support creating github users by their immutable GitHub id?