integrations / integrations/terraform-provider-github

[FEAT]: Add github_actions_*_fork_pr_contributor_approval resources and data sources

Open
#3,445 1 comment 6 reactions 0 assignees View on GitHub
Status: Triage Type: Feature
Dominant language
Go
Stars
1.2k
Forks
1k
Avg merge
1d 14h
Merged PRs (30d)
8

Description

### 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

- [x] GitHub.com (Free, Pro, or Team)
- [ ] GitHub Enterprise Server (on-premises)
- [x] GitHub Enterprise Cloud with Personal Accounts (github.com)
- [ ] GitHub Enterprise Cloud with Managed Users/EMU (github.com)
- [ ] GitHub Enterprise Cloud with Data Residency (*.ghe.com)
- [ ] I don't know

### Relevant log output

```shell
N/A — feature request.
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.