Skip to content

feat: add github_organization_invitation resource#3464

Open
nitinjain999 wants to merge 2 commits into
integrations:mainfrom
nitinjain999:feat/organization-invitation
Open

feat: add github_organization_invitation resource#3464
nitinjain999 wants to merge 2 commits into
integrations:mainfrom
nitinjain999:feat/organization-invitation

Conversation

@nitinjain999
Copy link
Copy Markdown

@nitinjain999 nitinjain999 commented Jun 1, 2026

Closes #2197

Picking up the work from #3229 (original author inactive) and addressing all maintainer review feedback.


Before the change?

github_membership only works when a user already has a GitHub account and is identified by their username. There was no way to invite someone to an org by email address, which is a common need when onboarding new users who may not yet have GitHub accounts.

After the change?

New resource github_organization_invitation:

# Invite by email
resource "github_organization_invitation" "example" {
  email = "newmember@example.com"
  role  = "direct_member"
}

# Invite by GitHub user ID
data "github_user" "invitee" {
  username = "someuser"
}

resource "github_organization_invitation" "example" {
  invitee_id = data.github_user.invitee.id
}

Changes vs #3229

All three issues flagged by @deiga are addressed, plus one additional bug found during testing:

  1. Redundant invitation_id computed field removed — the resource ID already is the invitation ID
  2. ctx = context.WithValue(ctx, ctxId, ...) removed from Read and Delete — not needed
  3. Idempotency fixed — when an invitation is no longer in the pending list, Read now checks whether the invitee accepted and became an org member via IsMember. If they are a member, the resource stays in state. Only if the invitee is neither pending nor a member (expired/cancelled) is the resource removed from state
  4. Email drift bug fixed — the GitHub API always returns the invitee's email in the invitation response, even for invitee_id-based invitations. The original PR set email from the API response unconditionally, which caused a perpetual destroy/recreate diff when invitee_id was the configured field. Now email is only written to state when the resource was created with email

Testing

invite_by_invitee_id PASSES verified against a real org (nitin-sv) with deiga as the external user.

invite_by_email and invite_with_admin_role skip when GH_TEST_INVITATION_EMAIL is not set — they require an email address not already associated with an org member.

Pull request checklist

  • Schema migrations have been created if needed — not applicable
  • Tests for the changes have been added
  • Docs have been reviewed and added / updated if needed

Does this introduce a breaking change?

  • Yes
  • No

Closes integrations#2197

Adds a new resource to invite users to a GitHub organization by email
address or GitHub user ID, using the CreateOrgInvitation API.

This addresses the limitation of github_membership which requires the
user to already be a GitHub user and cannot invite by email.

Addresses all review feedback from integrations#3229:
- Removed redundant d.Set("invitation_id", ...) — the resource ID is
  the invitation ID; a separate computed field is unnecessary
- Removed unnecessary ctx = context.WithValue(ctx, ctxId, ...) calls
- Fixed idempotency: when an invitation is no longer pending, Read now
  checks if the invitee became an org member (invitation accepted) and
  keeps the resource in state rather than blindly removing it, which
  would have caused a perpetual create loop
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Jun 1, 2026

👋 Hi, and thank you for this contribution!

This repo is maintained by GitHub and community members on a best-effort basis. We'll get to this as soon as we can.

You can help us prioritize by joining the discussion on open issues and PRs, sharing details on the changes you need, and reviewing other contributions.


🤖 This is an automated message.

@github-actions github-actions Bot added the Type: Feature New feature or request label Jun 1, 2026
@nitinjain999 nitinjain999 marked this pull request as ready for review June 1, 2026 05:56
The GitHub API always returns the invitee's email in the invitation
response, even for invitee_id-based invitations. Setting email in state
from the Read response caused a perpetual diff when the config used
invitee_id — each plan would propose to destroy and recreate.

Only set email in Read when the resource was originally created with email.
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

h

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

what you mean by h ?

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

Labels

New resource Type: Feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEAT]: github_membership invite using the email address

3 participants