Skip to content

fix(resource_github_organization_custom_properties): support bool default values - #3572

Open
secustor wants to merge 5 commits into
integrations:mainfrom
secustor:fix/custom-attributes
Open

fix(resource_github_organization_custom_properties): support bool default values#3572
secustor wants to merge 5 commits into
integrations:mainfrom
secustor:fix/custom-attributes

Conversation

@secustor

@secustor secustor commented Jul 23, 2026

Copy link
Copy Markdown

This is a minimal fix for users of default values and is intentionally tries not to reach the scope of #3234

Closes: #3580

Resolves infinite drift if when using resource_github_organization_custom_properties of value_type true_false and default_value.

Infinite terraform plan:

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # github_organization_custom_properties.stedisentry_enabled will be updated in-place
  ~ resource "github_organization_custom_properties" "foo" {
      + default_value      = "true"
        id                 = "foo"
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Before the change?

customProperty.DefaultValueString() will return "", nill because of https://github.com/google/go-github/blob/a3951f514384b06cc428f394672020c14f7efd84/github/orgs_properties.go#L59

resource "github_organization_custom_properties" "foo" {
  property_name = "foo"
  value_type    = "true_false"
  required      = true

  // currently there is an infinite drift setting creating an addition on each plan 
  default_value = "true" // `true` has the same behavior 
}

This forces following workaround

resource "github_organization_custom_properties" "foo" {
  property_name = "foo"
  value_type    = "true_false"
  required      = true

  default_value = "true"

  lifecycle {
    ignore_changes = [default_value]
  }
}

After the change?

With this instead customProperty.DefaultValueBool() is called and with that the return value is true, nill which will then correctly set in the state

Pull request checklist

  • Schema migrations have been created if needed (example)
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

  • Yes
  • No

@github-actions

Copy link
Copy Markdown

👋 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: Bug Something isn't working as documented label Jul 23, 2026
@deiga

deiga commented Jul 24, 2026

Copy link
Copy Markdown
Collaborator

Please mark clearly which issue this is going to resolve!

@secustor

Copy link
Copy Markdown
Author

Resolves infinite drift if when using resource_github_organization_custom_properties of value_type true_false and default_value.

I have been under the impression that the explanation above is clear enough, now there is also an example of the Terraform plan which will be generated on each plan and is not reconciled.

@deiga

deiga commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator

@secustor I meant which issue number/URL.
If no issue exists yet, please create one :)

@deiga deiga left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Thanks for the effort so far!

Comment thread github/resource_github_organization_custom_properties_test.go Outdated
Comment thread templates/resources/organization_custom_properties.md.tmpl

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

These provider review instructions are being used.

Fixes perpetual drift for boolean organization custom-property defaults by correctly reading and stringifying boolean API values.

Changes:

  • Handles true_false defaults during state refresh.
  • Adds regression coverage for empty follow-up plans.
  • Documents unsupported multi_select defaults.

Finding: The new test uses legacy assertion APIs instead of ConfigStateChecks.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File Description
github/resource_github_organization_custom_properties.go Reads boolean defaults correctly.
github/resource_github_organization_custom_properties_test.go Adds regression coverage.
templates/resources/organization_custom_properties.md.tmpl Documents default-value limitations.
docs/resources/organization_custom_properties.md Updates generated documentation.

Comment thread github/resource_github_organization_custom_properties_test.go Outdated
Use ConfigStateChecks/ExpectKnownValue for the true_false default_value
assertion instead of the legacy TestCheckResourceAttr Check, and note the
multi_select limitation in the default_value schema Description.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@secustor
secustor requested a review from deiga July 29, 2026 13:37
"default_value": {
Type: schema.TypeString,
Description: "The default value of the custom property",
Description: "The default value of the custom property. Not supported for multi_select properties.",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Would it make sense to add a validation to not use default with multi-select?

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.

My understanding is this would be breaking the setup for existing users which use the ignore_changes workaround 🤔

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I'm not sure that breaking the wrong way would be a problem. But if we want to be careful we should at least introduce a warning for this case

@secustor secustor Aug 8, 2026

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 kind of warning do you want me to add?

I see different patterns here in the repo.

  • Logging with log.Printf("[WARN] ...")
  • Using diagnostics, though that would need more changes in that PR
  • or simply in the docs

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

diagnostics would be the best, let's go with that 🙏

Comment thread github/resource_github_organization_custom_properties_test.go Outdated
Comment thread github/resource_github_organization_custom_properties_test.go Outdated
Drop the redundant default_value state check (Terraform core already
enforces consistency with config) and fold the drift regression guard
into a PostApplyPostRefresh plan check on the apply step.
@secustor
secustor requested a review from deiga August 5, 2026 13:43
…context-aware CRUD

Switches the resource to the CreateContext/ReadContext/UpdateContext/
DeleteContext and StateContext signatures used by most resources in the
provider, so the CRUD functions receive a context and can return
diagnostics instead of a bare error.

Update now delegates to Create, which already upserts via PUT and reads
the property back, removing a redundant second read.
…elect default_value

GitHub returns the default value of a multi_select property as a list of
strings, which cannot be represented by the string default_value
attribute. The value is therefore not stored in state and every plan
shows a change for default_value.

Emit a warning diagnostic on create and update instead of rejecting the
combination, so existing configurations relying on the ignore_changes
workaround keep working.
@stevehipwell

Copy link
Copy Markdown
Collaborator

I think #3234 should fix this, but if not this change would need to be made on top of the other PR.

@secustor

Copy link
Copy Markdown
Author

I think #3234 should fix this, but if not this change would need to be made on top of the other PR.

Potentially, I have referred this PR in the PR body.
The intention is to deliver a minimal fix until #3234 lands.

@stevehipwell

Copy link
Copy Markdown
Collaborator

@secustor I don't think it's worth fixing this resource given that it's going to be replaced, I'd rather incentivise people to remove -> import sooner than later.

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

Labels

r/organization_custom_properties Type: Bug Something isn't working as documented vNext

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG]: github_organization_custom_properties of type true_false detects drift on default_value indefinitely

4 participants