GitHub usernames are case-insensitive and should be treated that way

[dgmorales]

GitHub usernames are case-insensitive but case preserving. When searching in the UI and the API, the case does not matter, but the user found is returned with the proper username capitalisation defined by the user. The terraform GitHub provider needs to be aware of that.

When adding a user to an org with the github_membership resource, it will work with whatever casing you specify. BUT, when running again terraform will detect the username difference (dgMorales != dgmorales, for example) and report a change, and try to apply. When applied it will not thrown an error, but it will keep reporting the change again an again ...

Terraform Version

• Terraform v0.11.11
• provider.github: version = "~> 1.3"

Affected Resource(s)

• github_membership
• github_team_membership
• both above confirmed, but possibly also any other the accepts an username string as input (github_branch_protection, for example)

Terraform Configuration Files

See below.

Debug Output

To make a sensible debug output and configuration example, I need to refactor my code to portrait only this problem. I can do this in a few days, but I'm not sure that is really necessary or helpful in this case.

Below here I've placed an adapted excerpt from the regular output of my terraform plan. My GitHub username is dgmorales and suppose I specified dgMorales in my terraform code (here I'm wrapping the resources in a user module).

-/+ module.dgmorales_user.github_membership.org-member (new resource required)
      id:       "my-org-name:dgmorales" => <computed> (forces new resource)
      etag:     "W/\"<hex-numbers-string>\"" => <computed>
      role:     "member" => "member"
      username: "dgmorales" => "dgMorales" (forces new resource)

-/+ module.dgmorales_user.github_team_membership.all-org-members (new resource required)
      id:       "<team-id-number>:dgMorales" => <computed> (forces new resource)
      etag:     "W/\"<hex-numbers-string>\"" => <computed>
      role:     "member" => "member"
      team_id:  "<team-id-number>" => "<same-team-id-number>"
      username: "dgmorales" => "dgMorales" (forces new resource)

That shows both with -refresh=true or -refresh=false (the state is saved with the correct username case). It keeps happening after running apply.

Expected Behavior

I believe the provider should either:

1. Check the username is in a different case, and throw an error (despite having found the correct user)
2. Ignore differences in case only and not report a change for that.

I would vote on alternative 2.

Actual Behavior

Plan keeps reporting a change every time.

Steps to Reproduce

• Just use one of the resources mentioned and pass it an username in a different case than the actual username case.

Important Factoids

None.

References

We can see instances of this same problem in other projects:

• GitHub usernames are case-sensitive dropseed/pullapprove-support#35
• Capitalization of usernames mislav/hub#157
• Github usernames are case-insensitive lgtmco/lgtm#19

I haven't found a mention to this on GitHub doc, just this community question: https://git.luolix.topmunity/t5/How-to-use-Git-and-GitHub/Changing-username-case/m-p/6714?advanced=false&collapse_discussion=true&q=username%20case&search_type=thread

[majormoses]

Interesting that makes sense, while not quite the same thing case does affect labels as well https://github.com/terraform-providers/terraform-provider-github/issues/165#issuecomment-437402327. I could not find anything in their docs shedding further light on this matter. I did some poking around and I think it's not quite so straightforward. I would also lean towards ignoring case here for comparison but I think more investigation is needed. mislav/hub#157 (comment) outlines what I mean when I say there are probably some edge cases we need to be evaluated. We may very well find out that after outlining the edge cases we are not affected by them and its safe to use a case insensitive comparison but I think that's where we need to start unless we would rather error out with a helpful message.

[megan07]

Thanks @dgmorales for opening this issue. It's been closed with #241 and will be released shortly.