Repository navigation
fix: select owner secret for organization pings - #338
Conversation
Co-authored-by: Eduard Carreras <ecarreras@gisce.net>
|
Post-merge sync: #338 is merged as No dedicated PR #338 worktree exists in the local worktree registry or at the conventional path, so no cleanup was needed. This verifies merge/integration only; the production secret migration described in the PR body is a separate rollout and was not verified here. |
|
Correction to the post-merge sync: the local worktree registry does contain the dedicated PR worktree at /home/openclaw/projects/gisce-ti/worktrees/github-agent-bridge-owner-secret-ping, on fix/webhook-org-owner-secret at 3f2c569. It is clean, and I reran the three focused owner-secret regressions: 3 passed (repository owner selection, organization ping fallback, and unknown-owner rejection). The merged-code assessment stands, but worktree/branch cleanup is still pending. I did not remove either in this review-only run. |
Summary
organization.loginwhen an organization-hook payload has no repository;repository.full_nameas the first-choice owner for normal repository events;pingpayloads with per-owner secrets.Rollout impact
The planned migration from
GITHUB_AGENT_BRIDGE_WEBHOOK_SECRETtoGITHUB_AGENT_BRIDGE_WEBHOOK_SECRETS_BY_OWNERexposed this gap before the production services were restarted. A GitHub organization-hookpinghasorganization.loginbut norepository.full_name, so the current ingress rejects it withrepository_owner_not_allowedeven when the organization secret is configured.Production remains on the shared secret until this fix is released. No ingress traffic was switched to the incomplete configuration.
Validation
403) before the implementation and GREEN (200) after it;694 passedin the full Python suite;git diff --checkclean.Refs #299
TASK: TASK-85718