feat(repo-schema): manage allow_forking with ownership-aware default#62
Merged
Conversation
The GitHub API rejects any PATCH containing `allow_forks` on
personal-account private repositories — regardless of the value being
set. terraform-provider-github includes `allow_forks` in every PATCH
payload for `github_repository` resources by default, so deploys that
manage personal-account private repos always failed with 422
"Allow forks setting can only be changed on org-owned private
repositories", even though the framework didn't intentionally expose
the field in YAML.
This change makes `allow_forking` an opt-in YAML key with a default
policy that handles all three GitHub API behaviors:
YAML explicitly sets true/false:
Honor the value verbatim. Lets repos that need a specific fork
policy declare it.
YAML omits the key + visibility == "private"
+ var.github_is_organization == false:
Default null. The provider then omits `allow_forks` from PATCH,
bypassing the API rejection for personal-account private repos.
Every other case (public, internal, OR org-owned private):
Default false (secure-by-default; forks disabled unless YAML opts
in via `allow_forking: true`). GitHub's API accepts the field on
all three, so the framework can enforce the policy.
Concretely:
- terraform/30-locals.tf
`allow_forking` added to `allowed_repo_keys` (was rejected as
unknown-top-level-key before). Build expression in
`local.all_repositories` implements the three-way logic above.
- terraform/41-resources-github.tf
Resource now explicitly assigns
`allow_forking = each.value.allow_forking`. Removed
`allow_forking` from the lifecycle `ignore_changes` list —
drift in YAML-managed values should surface as a real diff.
- terraform/tests/validation.tftest.hcl
Removed `rejects_allow_forking` test (the framework now accepts
the key).
- terraform/tests/fixtures/bad-allow-forking/ (deleted)
Fixture is no longer "bad" under the new schema.
- terraform/tests/COVERAGE.md
G03 row repurposed to track the new positive coverage (apply-time
test against a synthetic provider is a follow-up).
Renders correctly under both ownership values:
- var.github_is_organization = false (personal-account):
private repos default null → no PATCH rejection.
- var.github_is_organization = true (org):
private repos default false → framework enforces secure default.
No DESIGN.md or README changes; the existing prose about rejecting
unknown keys still describes the general typo-protection behavior, and
`allow_forking` is now an allowed top-level key. A follow-up doc PR
can add a paragraph about the ownership-aware default if a maintainer
finds the YAML schema needs it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
Terraform Framework Test Results
Runs: 54 total, 54 passed, 0 failed, 0 skipped Full test outputCommit: 1e2594a |
2 tasks
NWarila
added a commit
to NWarila/github-terraform-runner
that referenced
this pull request
May 26, 2026
## Summary Bumps the framework pin to the allow_forking ownership-aware default fix. | | Before | After | |---|---|---| | \`uses:\` SHA | \`0b99965b\` | \`abda8e1f\` | | \`framework_ref:\` | \`0b99965b\` | \`abda8e1f\` | ## Why After this merges, the next \`Deploy GitHub Terraform\` run on \`main\` will succeed for personal-account private repos (Resume, Personal, github-sandbox) because the framework now omits \`allow_forks\` from PATCH payloads for that case. Was blocked by 422 since today's earlier deploy attempt. See [nwarila-platform/github-terraform-framework#62](nwarila-platform/github-terraform-framework#62). ## Test plan - [ ] PR validation green - [ ] After merge: \`Deploy GitHub Terraform\` succeeds on main (no 422 errors on the 3 private repos) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
NWarila
added a commit
that referenced
this pull request
May 26, 2026
## Summary Bumps \`integrations/github\` from \`6.10.2\` to \`6.12.1\` (3 minor versions). Motivated by the \`allow_forking\` provider-default behavior: 6.10.2 treats Terraform \`null\` as the schema default \`false\`, which causes the provider to always include \`allow_forks\` in PATCH payloads. PATCH then 422s on personal-account private repositories. 6.12.x may include nullable handling for \`allow_forking\` (the next deploy will confirm). If the upgrade resolves the 422, no further code changes are needed and the ownership-aware default landed in #62 will behave as intended. ## Changes - \`terraform/versions.tf\`: bump constraint \`6.10.2\` -> \`6.12.1\`. - \`terraform/.terraform.lock.hcl\`: remove the github provider entry so CI's \`terraform init\` regenerates it. AWS and time entries are unchanged. ## Test plan - [ ] Framework CI green (\`Validate & Test\` exercises terraform init/validate/test). - [ ] After merge: bump pin in \`NWarila/github-terraform-runner/.github/workflows/terraform-deploy.yaml\` and re-run \`Deploy GitHub Terraform\`. Expect the 3 personal-account private repos (Resume, Personal, github-sandbox) to apply without 422. ## Fallback If 6.12.1 doesn't fix the 422, follow-up PR adds \`managed: optional(bool, true)\` to the YAML schema and filters at the locals layer. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 task
NWarila
added a commit
that referenced
this pull request
May 26, 2026
Adds a status preamble to REVIEW_REMEDIATION_PLAN.md recording per-finding implementation state. 7 of 9 findings now marked Done (Finding 4 closed by this session's PRs #62/#63); 1 REJECTED per existing doc; 1 follow-up tracked (manage_codeowners_files opt-in flag). ## Test plan - [ ] CI green (markdownlint) Local: markdownlint-cli2 → 0 errors. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Makes `allow_forking` an opt-in YAML key with an ownership-aware default that handles all three GitHub API behaviors correctly.
Why
GitHub's API rejects any PATCH containing `allow_forks` on personal-account private repositories — regardless of the value being set. terraform-provider-github includes the field in every PATCH payload by default, so deploys that manage personal-account private repos always failed with:
```
422 Allow forks setting can only be changed on org-owned private repositories
```
even though the framework didn't intentionally expose the field in YAML. `lifecycle.ignore_changes = [allow_forking]` only prevents diff detection — it doesn't exclude the field from the PATCH payload.
What changes
Default policy
Test plan
Local: `terraform fmt -check -recursive terraform/` → clean. (Full `validate` blocked by local terraform 1.14.3 vs the pinned 1.15.4; CI exercises that.)