Describe the need
The integrations/terraform-provider-github v6 has no resource or data source for the GitHub fork PR contributor approval policy — i.e., the "Fork pull request workflows from
outside collaborators" setting on a repo/org's GitHub Actions general settings page. Today this can only be configured through the GitHub UI or out-of-band gh api calls,
which means there is no Terraform drift detection on what is a security-relevant control.
For organizations that publish public repositories and want a Terraform-managed baseline of "external contributor workflows require maintainer approval before they run,"
Proposed surface
Four new building blocks wrapping the existing GitHub REST API:
| Type |
Name |
Wraps |
| resource |
github_actions_repository_fork_pr_contributor_approval |
PUT /repos/{owner}/{repo}/actions/permissions/fork-pr-contributor-approval |
| resource |
github_actions_organization_fork_pr_contributor_approval |
PUT /orgs/{org}/actions/permissions/fork-pr-contributor-approval |
| data source |
github_actions_repository_fork_pr_contributor_approval |
GET /repos/{owner}/{repo}/actions/permissions/fork-pr-contributor-approval |
| data source |
github_actions_organization_fork_pr_contributor_approval |
GET /orgs/{org}/actions/permissions/fork-pr-contributor-approval |
Each accepts the documented approval_policy enum: first_time_contributors_new_to_github, first_time_contributors, all_external_contributors.
The API has no "off" state for this policy, so on Delete the resource resets to GitHub's documented default (first_time_contributors). This mirrors the precedent set by
github_actions_organization_permissions Delete, which resets to a permissive default.
The data sources are useful for callers that want to read current state before deciding whether to declare a managing resource — e.g., to keep per-repo configuration opt-in
rather than forcing a strictness value across every repo in an org.
Implementation notes
- go-github already exposes the matching service methods on ActionsService (GetForkPRContributorApprovalPermissions / UpdateForkPRContributorApprovalPermissions and the
Organization variants), so this is a thin provider-side wrapper — no upstream SDK work needed.
- Scope: ~100 LOC per resource + ~120 LOC per acceptance test, patterned on resource_github_actions_repository_access_level and
resource_github_actions_organization_permissions.
- Acceptance tests for all four resources pass against GH_TEST_AUTH_MODE=organization (repo-level tests use public visibility; private repos require the separate
fork-pr-workflows-private-repos org/repo settings to be configured first, and that's a distinct API surface).
- I have a PR ready against this issue, AI-assisted but personally reviewed and tested per the AI Use Policy.
GitHub Installation Type
Relevant log output
Code of Conduct
Describe the need
The integrations/terraform-provider-github v6 has no resource or data source for the GitHub fork PR contributor approval policy — i.e., the "Fork pull request workflows from
outside collaborators" setting on a repo/org's GitHub Actions general settings page. Today this can only be configured through the GitHub UI or out-of-band gh api calls,
which means there is no Terraform drift detection on what is a security-relevant control.
For organizations that publish public repositories and want a Terraform-managed baseline of "external contributor workflows require maintainer approval before they run,"
Proposed surface
Four new building blocks wrapping the existing GitHub REST API:
Each accepts the documented approval_policy enum: first_time_contributors_new_to_github, first_time_contributors, all_external_contributors.
The API has no "off" state for this policy, so on Delete the resource resets to GitHub's documented default (first_time_contributors). This mirrors the precedent set by
github_actions_organization_permissions Delete, which resets to a permissive default.
The data sources are useful for callers that want to read current state before deciding whether to declare a managing resource — e.g., to keep per-repo configuration opt-in
rather than forcing a strictness value across every repo in an org.
Implementation notes
Organization variants), so this is a thin provider-side wrapper — no upstream SDK work needed.
resource_github_actions_organization_permissions.
fork-pr-workflows-private-repos org/repo settings to be configured first, and that's a distinct API surface).
GitHub Installation Type
Relevant log output
Code of Conduct