feat(actions): manage artifact and log retention

[yordis]

Resolves #3599

---

Before the change?

• Artifact and log retention had to be set by hand in the UI at every scope, so a storage-cost and data-retention control sat outside Terraform and drifted silently. [FEAT]: Support for setting the retention period for Github Actions artifacts and logs #2150 asked for this and was closed as not planned in Nov 2024 because the API did not support it; the endpoints have shipped since.

After the change?

• Retention is now declarable at repository and organization scope, so the setting is reviewable and enforced like the rest of an Actions configuration.

Two behaviours worth calling out, because they are forced by the API rather than chosen:

• There is no endpoint to clear a customised value, only to set one. Destroy therefore writes GitHub's default of 90 days back rather than restoring "never customised", which is not observable through the API.
• A value above the scope's ceiling is rejected with 409, and the organization value becomes each repository's ceiling. Destroy writes min(90, maximum_allowed_days) so that resetting a repository under an organization with a lower ceiling does not fail.

Enterprise scope is deliberately left out of this PR to keep it reviewable; I have no enterprise account to test it against.

How this was verified

Beyond the acceptance tests, both resources were run end to end against a real organization and a throwaway repository, using a locally built provider through dev_overrides, on OpenTofu 1.9.0 with real credentials and remote state. Organization and repository names are elided below.

Check	Result
Organization create	1 added; GET /orgs/{org}/actions/permissions/artifact-and-log-retention returns the configured value
Ceiling propagation	after setting the organization value, every repository reports it as both days and maximum_allowed_days
Idempotency	re-plan reports no changes, plan -detailed-exitcode exits 0
Update	in place, ~ days = 7 -> 30, no replacement
Drift detection	changed out of band to 15 via the API; the next plan proposed 15 -> 30, 1 to change
Import	after state rm, import <org> hydrated days and maximum_allowed_days, and the follow-up plan exited 0
Validation	days = 0 and days = 401 are both rejected with expected days to be in the range (1 - 400)
Repository create	succeeded below the organization ceiling, with repository_id computed
Repository create above the ceiling	rejected with the 409 reason surfaced, see below
Repository destroy under a lower ceiling	wrote 30, the ceiling, rather than 90; a fixed PUT of 90 would have failed with 409 here
Organization destroy	wrote 90 back
Deleted repository	read drops the resource from state instead of erroring
Organization acceptance test	passes against a real organization with TF_ACC=1, and restores the original value on cleanup

One note on the small error helper in this PR, since it is the least obvious part of the diff. These two endpoints return their rejection reason in an errors field holding a plain string rather than the usual array, so CheckResponse cannot decode it into ErrorResponse and discards the parsed error, including Message. Users saw only:

Error: PUT https://api.github.com/repos/{owner}/{repo}/actions/permissions/artifact-and-log-retention: 409  []

go-github does restore the raw body onto the response, which is the only place the reason survives, so the helper reads it back and the same failure now reports:

Error: Conflict

  Artifact and log retention settings are limited by the organization to 30 days

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)

New resources, so no migration is needed.

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

I used an AI assistant while writing this. I have read every line, verified the API behaviour against the REST docs and against live calls rather than taking the model's word for it, and ran the resources end to end against a real organization before opening this, as tabulated above.

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

[deiga]

Please have only 1 PR open for review at a time

[yordis]

@deiga I am just running into the limitations and deciding to contribute. I am not opening for code review without properly test the features against my own org.

Do you prefer if I make 1 PR with everything?

[deiga]

@yordis We have very limited capacity for new features at this moment and are going to start enforcing a 1 open PR per new contributor rule.

Please don't combine multiple PRs into one, but just have 1 PR open that is self-contained.

If you want to increase your chances of getting your PR merged, it would be highly appreciated if you can review other open PRs and spot anything that should be addressed by the authors.