Repository navigation
Closed as not planned
Closed as not planned
Copy link
Description
The organisation setting that allows deploy keys is declared in src/opentofu/github, so it cannot drift away from what Flux on the PC needs.
Caller
- The PC creates its age key once and reaches platform-secrets with its own read-only deploy key #61 (the PC's deploy key on platform-secrets): Flux on the PC fetches the private repository
platform-secretswith a read-only deploy key. GitHub refuses the key while the organisation'sdeploy_keys_enabled_for_repositoriesis false. On 07.11.2026 that flag was false, and the operator set it to true by hand at The PC creates its age key once and reaches platform-secrets with its own read-only deploy key #61's host step B6, withgh api -X PATCH orgs/overnightworks. The deploy key, not a GitHub App or a PAT, was weighed in chat that day: an App's private key sits on the PC just as unprotected, and the PC holds the age key anyway. - Every fleet repository's GitHub settings and the organisation rulesets live as code in platform #10, which puts the fleet's GitHub settings into code. Today this one is set by hand and owned by no root.
Done when
src/opentofu/githubdeclaresdeploy_keys_enabled_for_repositories = truefor the organisationovernightworks. A plan withscripts/apply_github_settings.shshows no other organisation setting changing. If the only resource that carries the flag (github_organization_settingsin integrations/github 6.13.0) would take over and reset other organisation settings, the plan names each one, and the slice either declares them at their live values or stops and names the alternative.mise run github:testis green. The mocked test pins the flag's relationship to the PC's deploy key, not a copied literal.- The operator's
--applychanges nothing on the live organisation, because the flag is already true.
Unknown, for its plan
- Whether
github_organization_settingsrequiresbilling_emailand other attributes, and resets unset ones to provider defaults. Read the provider's schema at 6.13.0 and plan against the live organisation before building.
version = 1
now = "Opened 07.11.2026 after the operator enabled deploy keys for the organisation by hand at #61's B6."
next = "Plan: read github_organization_settings at 6.13.0 and plan against the live organisation, then declare the flag without changing any other setting."
done_when = "src/opentofu/github declares deploy_keys_enabled_for_repositories = true for overnightworks; its plan changes no other organisation setting; mise run github:test is green; the operator's apply changes nothing live."
scope = [
"src/opentofu/github",
]
size = "S"
whole = "The organisation resource, its test and the root's lock change together in one root."
Metadata
Metadata
Assignees
Labels
No labels
Activity
FlexOr2 commentedon Nov 7, 2026
Closed as not planned: the flag cannot be declared yet.
deploy_keys_enabled_for_repositories.github_organization_settingshas 27 attributes, none of them this one;github_rest_apiis only a data source. Upstream, [FEAT]: Expose remaining org attributes in github_organization_settings integrations/terraform-provider-github#3388 ("Expose remaining org attributes in github_organization_settings") is open. Evidence:tofu providers schema -jsonat the committed lock.gh api orgs/overnightworksshows it, as the operator set it at The PC creates its age key once and reaches platform-secrets with its own read-only deploy key #61's B6.github_rest_apidata source with a precondition would fail the plan when the flag is false. It would add code that catches a drift only when someone plans GitHub settings. That is no earlier than the failure on the PC, whereplatform-secretsgoes not Ready andbootstrap:secretsnames the deploy key.platform-secrets. That is visible at once and recovered with one PATCH. The gap is recorded on Every fleet repository's GitHub settings and the organisation rulesets live as code in platform #10.Reopen when integrations/github ships the attribute in
github_organization_settings. Then declare it as this body says.