Add github_code_security_configuration resource

[mushhzz]

Resolves #2412

---

Before the change?

• There is no way to manage Code Security Configurations with this provider; they must be managed via the UI/API.

After the change?

• Adds a single github_code_security_configuration resource that manages a configuration at either the organization level (default, using the provider owner) or the enterprise level (set enterprise_slug, which is ForceNew).
• Covers every configuration attribute exposed by go-github v89, including the nested option blocks (dependency_graph_autosubmit_action_options, code_scanning_default_setup_options, code_scanning_options, secret_scanning_delegated_bypass_options with reviewers) and the newer dependabot_delegated_alert_dismissal and secret_scanning_extended_metadata settings.
• Manages default_for_new_repos through the /defaults endpoints, with full read-back so drift is detected.
• Context-aware CRUD, tflog, 404 handling on read and delete, ConfigStateChecks/plancheck-based tests with t.Parallel(), tfplugindocs docs and examples.

Design notes

• Attribute categories. Attributes that existed in the first revision keep a schema Default and are always sent. Attributes added since are Optional-only: sent to the API and tracked in state only when present in configuration, so GitHub keeps its own value for anything the user has not chosen to manage. This follows the Optional-only direction from the feat: Add github_organization_security_configuration and github_enterprise_security_configuration resource #3284 review. The docs call out the two categories explicitly.
• Delegated bypass reviewers. The API rejects secret_scanning_delegated_bypass_options.reviewers on the initial create request but accepts them on update, so create applies them in a follow-up update call.
• attach_scope was removed. Attaching a configuration to repositories is a fire-and-forget action the API cannot read back, which does not fit a declarative resource. It can be added later as its own resource if there is demand.
• Relationship to feat: Add github_organization_security_configuration and github_enterprise_security_configuration resource #3284 and Implement code security configuration resource for organziations #2664. Implement code security configuration resource for organziations #2664 predates the current repo conventions. feat: Add github_organization_security_configuration and github_enterprise_security_configuration resource #3284 models this as two resources plus a shared util file; this PR uses one resource keyed on enterprise_slug, which removes roughly 500 lines of duplicated schema and CRUD while covering a superset of its attributes. Happy to align on whichever shape the maintainers prefer.

Verification

• go build, go vet, gofmt, golangci-lint (default config: 0 issues; strict config on new code: 0 issues in these files) and tfplugindocs validate are clean.
• Acceptance tests cover org create → update → import, nested option blocks create → update → empty plan, default_for_new_repos set → change → remove → empty plan, and enterprise create → update → import.
• Note: the latest revision has not yet been run against a GHAS-enabled org; earlier revisions were. Maintainer CI approval would be appreciated.

Pull request checklist

• Schema migrations have been created if needed (not needed — new resource)
• 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?

• Yes
• No

[github-actions]

👋 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.}

[Copilot]

Pull request overview

These provider review instructions are being used. Adds organization- and enterprise-level GitHub Code Security Configuration management. Blocking reliability and test issues are noted inline.

Changes:

• Adds full CRUD and import support.
• Registers the resource and adds acceptance tests.
• Adds examples and generated documentation.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
github/resource_github_code_security_configuration.go	Implements schema, CRUD, import, defaults, and attachment behavior.
github/resource_github_code_security_configuration_test.go	Adds organization and enterprise acceptance tests.
github/provider.go	Registers the resource.
examples/resources/code_security_configuration/example_1.tf	Demonstrates typical usage.
templates/resources/code_security_configuration.md.tmpl	Defines documentation content.
docs/resources/code_security_configuration.md	Adds generated resource documentation.

[mushhzz]

Thanks for the Copilot review — really useful pass! I've addressed the feedback in 5e15072:

• Context-aware CRUD: migrated to CreateContext/ReadContext/UpdateContext/DeleteContext with diag.Diagnostics, threading the provided context through all API calls. Create now sets its computed fields directly rather than chaining Read.
• Logging: all stdlib log calls replaced with structured tflog per DECISIONS.md.
• Delete: a 404 is now treated as already-deleted, so terraform destroy succeeds if the configuration was removed out-of-band.
• Attach path: swapped the go-github v89 attach helpers (which can nil-deref on transport failures) for a nil-safe direct client.NewRequest/client.Do call; that helper issue looks worth an upstream go-github report.
• Tests: all steps converted to ConfigStateChecks + statecheck/knownvalue/plancheck per DECISIONS.md, and added new acceptance coverage for default_for_new_repos (set → change → remove → empty plan) and attach_scope (set + idempotent re-plan).

The one comment I didn't action is the new(d.Get(...).(string)) one — Go 1.26 (declared in go.mod) allows new(expr), and the repo already uses this idiom elsewhere; details in the thread reply.

make test, go vet, gofmt, and go build are all clean after the changes. Happy to adjust anything further!

[deiga]

What makes this PR better than #3284 or #2664?

[mushhzz]

@deiga fair question, and the honest answer changed today because I pushed a revision (f78a022) to close the gaps.

#2664 is stale: go-github v66, legacy CRUD, no docs, no response since January.

Versus #3284, this PR now:

• Covers every attribute in go-github v89, a superset of feat: Add github_organization_security_configuration and github_enterprise_security_configuration resource #3284 (it adds dependabot_delegated_alert_dismissal and secret_scanning_extended_metadata).
• Uses a single resource for org and enterprise, keyed on enterprise_slug (ForceNew), instead of two resources plus a shared util file. Roughly 500 fewer lines to maintain for the same surface.
• Manages default_for_new_repos with full read-back via the /defaults endpoints, tested set -> change -> remove -> empty plan.
• Follows the Optional-only direction from the feat: Add github_organization_security_configuration and github_enterprise_security_configuration resource #3284 review for new attributes, colocates all state logic in the resource file, and uses ConfigStateChecks + plancheck with t.Parallel().
• Handles the API 500 on delegated-bypass reviewers at create time by deferring them to an update.

I removed attach_scope from this revision; it was write-only and did not fit a declarative resource.

I'm not attached to which PR lands. If you'd prefer #3284's two-resource shape, I'm happy to close this and contribute the missing attributes and default_for_new_repos handling there. If the single-resource shape is preferred, this one is ready for review and just needs CI approved on the fork.

[casey-robertson-paypal]

@mushhzz it will sound self-serving but the current PR I'm involved with has far more maintainer feedback #3284 - I think we should focus on getting this one over the line?