feat: add github_repository_custom_properties resource for batch property management by mkushakov · Pull Request #3237 · integrations/terraform-provider-github

mkushakov · 2026-02-27T16:49:18Z

Resolves #3240

Summary

Add a new github_repository_custom_properties resource (plural) that manages multiple custom property values on a single repository in one resource block, with in-place updates when values change.

This complements the existing github_repository_custom_property resource (singular), which manages one property per resource instance and requires destroy+recreate on any change.

Motivation

The existing singular github_repository_custom_property resource has limitations:

All fields are ForceNew — changing a property value destroys and recreates the resource, even though the GitHub API supports PATCH
One resource per property — managing 10 properties on a repo requires 10 resource blocks
Requires property_type — the user must manually specify the property type, even though it's already defined at the org level
One API call per property — no batching

The new plural resource addresses all of these:

Capability	Singular (`github_repository_custom_property`)	Plural (`github_repository_custom_properties`)
Properties per resource	1	N
Value change behavior	Destroy + recreate	In-place update
Requires `property_type`	Yes	No (auto-detected from org definitions)
API calls	1 per property	1 for all properties (batch)
Import	`owner/repo/property_name`	`owner/repo` (imports ALL properties)

Changes

New Resource (`resource_github_repository_custom_properties.go`)

Schema with repository_name (ForceNew) and property (TypeSet of name/value blocks)
Create and Update share the same function — looks up org property definitions to auto-detect types, then calls CreateOrUpdateCustomProperties with all properties in a single API call
Read filters to only managed properties (from state), or imports ALL properties when state is empty (import case)
Delete sets all managed properties to nil in a single API call
Custom StateContext importer that accepts owner/repo format and imports all properties
Hash function based on property name only (not values), so value changes are detected as in-place modifications
checkOrganization guard on all CRUD operations
Proper error wrapping with fmt.Errorf and %w

Provider Registration (`provider.go`)

Registered as github_repository_custom_properties

Tests (`resource_github_repository_custom_properties_test.go`)

Creates and reads multiple properties — sets two properties (single_select + string) and verifies
Updates property value in place — changes a single_select value from "production" to "staging" without destroy
Imports all properties — creates properties, then imports via owner/repo
Creates multi_select property — verifies multi-value property handling

All tests use providerFactories (modern pattern) and skipUnlessHasOrgs.

Example Usage

resource "github_repository_custom_properties" "example" {
  repository_name = github_repository.example.name

  property {
    name  = "environment"
    value = ["production"]
  }

  property {
    name  = "team"
    value = ["platform"]
  }

  property {
    name  = "languages"
    value = ["go", "typescript"]  # multi_select
  }
}

Relationship to Existing Resources

github_repository_custom_property (singular) — unchanged, still available. Users can choose whichever pattern fits their workflow.
github_organization_custom_properties — defines properties at the org level. The new resource reads these definitions to auto-detect property types.
data.github_repository_custom_properties (data source) — already exists, reads all properties for a repo.

Note: Using both singular and plural resources on the same repository and property is not recommended, as they would conflict. Users should choose one pattern per repository.

Testing

go build ./... — passes
go vet ./... — passes

github-actions · 2026-02-27T16:49:27Z

👋 Hi! Thank you for this contribution! Just to let you know, our GitHub SDK team does a round of issue and PR reviews twice a week, every Monday and Friday! We have a process in place for prioritizing and responding to your input. Because you are a part of this community please feel free to comment, add to, or pick up any issues/PRs that are labeled with Status: Up for grabs. You & others like you are the reason all of this works! So thank you & happy coding! 🚀

mkushakov · 2026-03-13T10:07:57Z

@deiga / @stevehipwell , any chances for reviewing this PR?

deiga · 2026-03-13T10:13:04Z

@mkushakov please don't ping us multiple times.
We have our own lives and work, OSS is usually a best effort situation when there is capacity for it.

If you currently have capacity for these PRs maybe you could review the last few merged PRs to look at what are things we usually ask for?

mkushakov · 2026-03-13T10:27:40Z

@mkushakov please don't ping us multiple times. We have our own lives and work, OSS is usually a best effort situation when there is capacity for it.

If you currently have capacity for these PRs maybe you could review the last few merged PRs to look at what are things we usually ask for?

sorry, don't want to be PITA, just want to see what is a way forward to backport most important changes from our fork so we can move back to this upstream
also i know there are a many people who also will benefit from this fixes/features

deiga

Partial review

New resource for managing multiple custom property values on a repository in a single resource block with in-place updates. Complements the existing singular github_repository_custom_property resource.

- Use context-aware CRUD functions (CreateContext, ReadContext, etc.) - Rename repository_name to repository, add computed repository_id field - Add CustomizeDiff with diffRepository for repo rename support - Separate Create and Update into distinct functions - Use buildID/parseID2 with : separator instead of buildTwoPartID - Replace log.Printf with tflog for structured logging - Return d.Set errors instead of swallowing them - Extract filterManagedCustomProperties to reduce cognitive complexity - Update tests to use ConfigStateChecks and extract duplicate literals - Update import format to accept repository name (owner from provider) - Update documentation to reflect schema changes

…tom-properties-resource

deiga · 2026-04-26T13:09:35Z

+	client := meta.(*Owner).v3client
+	owner := meta.(*Owner).name
+
+	_, repoName, err := parseID2(d.Id())


suggestion: Instead of parsing the repo name from Id it's recommended to use d.Get the field since it exists

deiga · 2026-04-26T13:11:53Z

+		return diag.FromErr(fmt.Errorf("error reading custom properties for repository %s/%s: %w", owner, repoName, err))
+	}
+
+	managedProperties, err := filterManagedCustomProperties(allCustomProperties, managedPropertyNames, isImport)


issue: this makes the resource non-authoritative which can encourage patterns that cause constant drift and confusion.
What do you think about this?

The resource is intentionally non-authoritative: it only manages the properties explicitly declared in the property {} blocks and ignores everything else on the repository.

Why non-authoritative:

Organizations often have custom properties managed by multiple teams, tools, or projects. Authoritative behavior would force all properties into a single resource block, which is impractical and fragile.

An authoritative resource that deletes unmanaged properties on apply can be destructive, especially during gradual adoption.

This matches how the existing singular github_repository_custom_property already works — it doesn't touch other properties either.

Many mature providers (e.g. GCP IAM bindings, AWS) offer non-authoritative variants for exactly this reason.

Regarding drift: only the declared properties are tracked, so there's no "phantom drift" from externally managed properties. If someone changes a managed property outside Terraform, the next plan correctly detects and fixes it.

I've updated the documentation and the resource description to explicitly call out the non-authoritative behavior so it's clear to users. See this commit.

deiga · 2026-04-26T13:12:13Z

+	// Read actual properties from GitHub
+	allCustomProperties, _, err := client.Repositories.GetAllCustomPropertyValues(ctx, owner, repoName)
+	if err != nil {
+		return diag.FromErr(fmt.Errorf("error reading custom properties for repository %s/%s: %w", owner, repoName, err))


You can use diag.Errorf

deiga · 2026-04-26T13:50:27Z

+	// If no properties exist, remove resource from state
+	if len(managedProperties) == 0 {
+		tflog.Warn(ctx, "No custom properties found, removing from state", map[string]any{"owner": owner, "repository": repoName})
+		d.SetId("")
+		return nil
+	}


question: I'm wondering if this makes sense as it will cause the resource to be recreated unnecessarily?
If this was an authorative resource I could fathom the purpose.
Could you elaborate on the use-case here?

This guard handles the edge case where all managed properties have been removed externally (e.g., the org-level property definitions were deleted). Since the resource has nothing left to manage, removing it from state makes Terraform surface the discrepancy on the next plan — the user sees the resource will be recreated, which prompts them to either fix the org definitions or remove the resource from their config.

Without this, the Read would silently succeed with an empty property set, which would conflict with the MinItems: 1 constraint and could cause confusing plan output.

That said, I'm open to alternative approaches — e.g., returning a warning diagnostic instead of removing from state, if you think that would be less surprising.

deiga · 2026-04-26T14:18:47Z

issue: Using SetSizeExact in the tests is hazardous as the resource is non-authorative. It's possible that there are other properties configured in the Test Org

deiga · 2026-04-26T14:20:38Z

+				},
+				{
+					Config: configUpdate,
+					ConfigStateChecks: []statecheck.StateCheck{


issue: Please add Plan checks to verify that it does in-place updates https://developer.hashicorp.com/terraform/plugin/testing/acceptance-tests/plan-checks/resource

deiga · 2026-04-26T14:21:32Z

+			Steps: []resource.TestStep{
+				{
+					Config: config,
+					ConfigStateChecks: []statecheck.StateCheck{


issue: The checks don't verify that it's a multi-select property, should they?

deiga · 2026-04-26T14:23:33Z

+	if err != nil {
+		return diag.FromErr(fmt.Errorf("error deleting custom properties for repository %s/%s: %w", owner, repoName, err))
+	}


issue: This also needs to check if the repo is deleted or archived, in which case the error is not an error

deiga · 2026-04-26T14:25:43Z

+	properties := d.Get("property").(*schema.Set).List()
+	if len(properties) == 0 {
+		return nil
+	}


question: What use case does this guard against? The Schema defines property as min 1 item, so we should never have 0 properties, right?

…r and import management

…improve error handling Co-authored-by: Copilot <[email protected]>

…ory not found scenarios Co-authored-by: Copilot <[email protected]>

github-actions Bot added the Type: Feature New feature or request label Feb 27, 2026

deiga requested changes Mar 13, 2026

View reviewed changes

mkushakov added 2 commits March 20, 2026 23:19

feat: add github_repository_custom_properties resource (batch)

6892990

New resource for managing multiple custom property values on a repository in a single resource block with in-place updates. Complements the existing singular github_repository_custom_property resource.

docs: add github_repository_custom_properties resource documentation

26bf410

mkushakov force-pushed the feat/repository-custom-properties-resource branch from dee9827 to fd4c6dd Compare March 20, 2026 22:25

mkushakov force-pushed the feat/repository-custom-properties-resource branch from fd4c6dd to e6829dc Compare March 20, 2026 22:26

Merge remote-tracking branch 'upstream/main' into feat/repository-cus…

45fe96e

…tom-properties-resource

mkushakov requested a review from deiga April 24, 2026 08:13

deiga requested changes Apr 26, 2026

View reviewed changes

mkushakov and others added 3 commits April 27, 2026 17:17

docs(repository_custom_properties): clarify non-authoritative behavio…

18c09b5

…r and import management

feat(repository_custom_properties): enhance resource description and …

c1fcd97

…improve error handling Co-authored-by: Copilot <[email protected]>

fix(repository_custom_properties): improve error handling for reposit…

03d7c07

…ory not found scenarios Co-authored-by: Copilot <[email protected]>

Conversation

mkushakov commented Feb 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

Changes

New Resource (resource_github_repository_custom_properties.go)

Provider Registration (provider.go)

Tests (resource_github_repository_custom_properties_test.go)

Example Usage

Relationship to Existing Resources

Testing

Uh oh!

github-actions Bot commented Feb 27, 2026

Uh oh!

mkushakov commented Mar 13, 2026

Uh oh!

deiga commented Mar 13, 2026

Uh oh!

mkushakov commented Mar 13, 2026

Uh oh!

deiga left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mkushakov commented Feb 27, 2026 •

edited

Loading

New Resource (`resource_github_repository_custom_properties.go`)

Provider Registration (`provider.go`)

Tests (`resource_github_repository_custom_properties_test.go`)