workflows: read protected owners and drift reviewers from deployment environments

[dev-milos]

What

PROTECTED_OWNERS and DRIFT_REVIEWERS were the only pieces of deployment config still living as repository-level variables in the config repo, handed to the reusable workflows as workflow_call inputs. Everything else — APP_ID, WORKSPACE, app_private_key, tfc_token — already comes from the deployment environment the job runs in, or from the caller's secrets: block.

Both are now read from the environment directly, and the inputs are gone.

• tf-plan.yaml — the validate job joins terraform-plan in the plan environment and reads vars.PROTECTED_OWNERS.
• drift-check.yaml — reads vars.DRIFT_REVIEWERS from the schedule environment it already ran in.

The composite actions (validate-org-configs, drift-pr) keep their inputs unchanged; only what feeds them changed.

Why

It puts the protected-owner list behind the same gate as the rule it backs. validate-org already refuses to read its schema or its owner list from the config repo, so that a pull request cannot weaken the rule it is validated against. The value itself now sits behind the plan environment's branch policy rather than in an open repository variable.

It removes a hand-off that could be dropped. The inputs meant every config repo had to remember to wire the value through its own caller. Reading it from the environment removes that step.

validate was the only job in the repo outside any environment. It joins plan rather than getting one of its own: a dedicated environment would be auto-created empty on first use in config repos that had not set it up.

Two behaviour changes worth reviewing

An empty protected-owner list is now a failure, not a warning. Moving the value behind an environment does not close the fail-open on its own — an unset variable still resolves to "" and hit the same warn-and-exit-0 branch, so a repo that bumped the ref without wiring the variable would have got a green check and no enforcement. validate-org now fails instead, but only when organisation/ config is actually present: an unconditional error would break config repos that manage repositories and nothing else. It is reported through the existing failures slice rather than returned early, so schema errors still surface in the same run.

Protection rules on plan now cost twice. They apply per job, and validate runs in this environment too. A consumer that had required reviewers on plan for the terraform-plan job now needs two approvals per pull request, and the author sees no validation feedback until the first one lands. Documented as a [!WARNING] rather than silently inherited.

Also: protected owner logins are no longer echoed to the logs. Actions logs on a public config repo are world-readable while repository variables are not, so printing the list widened its exposure rather than narrowing it. The count alone confirms the value was read.

Before merging

Both steps are additive and safe to do now — nothing reads the new variables until a config repo's pinned ref moves to a tag containing this PR. Doing them before the merge means there is no window in which the protected-owner check is off.

Needs admin on the config repo. Copy the current values across; do not retype them.

• gr-oss-developers/github-configuration → Settings → Environments → plan → add variable PROTECTED_OWNERS, value copied from the existing repository variable of the same name.
• Same repo → Settings → Environments → schedule → add variable DRIFT_REVIEWERS, value copied from the existing repository variable of the same name.

Leave the repository-level variables in place for now — the currently pinned ref still reads them through the inputs.

After merging

1. Tag a release containing this PR.
2. In the config repo, one commit that bumps the pinned ref and drops protected_owners: / reviewers: from the with: blocks. Both must move together: a caller that still passes a removed input fails immediately with Invalid input.
3. Once a run succeeds, delete the repository-level PROTECTED_OWNERS and DRIFT_REVIEWERS.

Important

Step 3 is not just tidying — it is the verification. Environment variables take precedence over repository variables of the same name, so if the environment variable were missing, vars.PROTECTED_OWNERS would quietly fall back to the repository one and everything would still look fine. Deleting the repository variables is what proves the value is actually coming from the environment.

Repository-level WORKSPACE / TFC_TOKEN are untouched — the decommission discover job runs outside any environment and needs them.

Verified end to end on milos-org/github-configuration

With the caller no longer passing either input, and plan carrying the same main deployment branch policy as gr-oss-developers:

Test	Result
organisation/members.yaml with the protected owner present	Enforcing 1 protected owner(s) → validate ✅, terraform-plan ✅
protected owner absent	protected owner … is missing from members.yaml → validate ❌, terraform-plan skipped
validate under the plan branch policy	✅ — no approval wait, policy satisfied via the workflow_run default-branch context
drift check	drift PR opened with the reviewer requested

go test ./... and actionlint are clean.