fix(repositories): stop sending webCommitSignoffRequired on repo updates#111
fix(repositories): stop sending webCommitSignoffRequired on repo updates#111devantler wants to merge 1 commit into
Conversation
Every managed repo update currently fails. Both agent-skills and agent-plugins went Synced=False ~2 minutes after #110 merged: update failed: async update failed: failed to update the resource: PATCH https://api.github.com/repos/devantler-tech/agent-skills: 422 Commit signoff is enforced by the organization and cannot be disabled This is not specific to those two repos — it is the FIRST TIME the update path has ever run. Every repo adopted its settings via LateInitialize, so Crossplane had only observed repo settings, never written them; ksail's 20 topics were imported, not applied. #110 is the first commit to change a managed field on an already-adopted repo, so it is the first real exercise of update. The shared patch pinned webCommitSignoffRequired: true on the reasoning that the provider "must always send true" to avoid exactly this 422. That reasoning was never validated, and the live state disproves it: spec is already true, the repo is true, every sibling is true, and the org is true — yet the PATCH is rejected. The field is org-controlled, so GitHub refuses a repo-level PATCH that carries it at all; the value is irrelevant. Omitting it lets the provider leave it out of the payload. Signoff stays enforced because the ORG enforces it, which is the only place it can be set. Cannot regress: if the provider still emits a zero-value false, the outcome is the same 422 that is already happening. Verified `kubectl kustomize deploy/` builds clean, the field renders nowhere, and the topics from #110 are unaffected.
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fb23aa8e26
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Closing — this change is a no-op, as Codex correctly flagged (P1) and I confirmed against the live cluster: Removing the field from the kustomize patch does not keep it out of the spec: it is an observed field and The underlying problem is real and unchanged (declarative repo-settings updates are write-blocked), but the fix touches the Observe-first + Full diagnosis, scope, and candidate approaches with trade-offs: #112. |
Why
Declarative repo management is currently write-blocked: any change to a managed repository setting fails against GitHub, so config merged into this repo silently never reaches the actual repos. It surfaced when the topics change in #110 merged — those two repos have been failing to sync ever since, with the settings still unapplied.
The cause is a setting we send that GitHub controls at the organisation level and refuses to accept per-repo. We had pinned it deliberately, but that decision was never actually tested — until now no repo setting had ever been changed, only imported, so the write path had never run once.
What
Stops sending that org-controlled setting. It stays enforced, because the organisation enforces it — that is the only place it can be set. This should unblock every future repo-settings change, starting with the topics from #110.
Please watch this one after merge rather than assume it worked — it is a hypothesis with strong evidence, not a certainty, and the check is whether
agent-skillsandagent-pluginsgo back toSynced=Trueand their topics appear. It cannot make things worse: the failure mode if wrong is the identical error we already have.Part of devantler-tech/monorepo#2229