docs: add RFC for service webhook auto-repair mechanism #4321
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / Why we need it:
This PR proposes an auto-repair mechanism for service webhooks that have been manually deleted from code repositories (GitLab/GitHub/Gerrit/Gitee).
Current Problem:
Solution:
During service updates, the system will automatically:
This eliminates manual intervention and ensures continuous webhook availability.
What is changed and how it works?
Design Document: community/rfc/2025-01-10-service-webhook-auto-repair.md
Key Changes:
- GitLabClient.WebHookExists(owner, repo, hookID)
- GitHubClient.WebHookExists(owner, repo, hookID)
- GerritClient.WebHookExists(repo, remoteName, hookID)
- GiteeClient.WebHookExists(owner, repo, hookID) (public/private)
- Only verify during service updates (not during creation)
- Execute asynchronously using goroutine to avoid blocking
- Verification failures do not affect the main workflow
- VerifyAndRepairWebhook(): Query webhook record, verify existence, recreate if missing
- checkWebhookExists(): Platform-specific webhook verification
Workflow:
Multi-platform Support:
Key Constraints:
Does this PR introduce a user-facing change?
User-Facing Impact:
Improved availability: Webhooks are automatically repaired without manual intervention
No breaking changes: Completely backward compatible, no API or database modifications required
Transparent to users: Auto-repair happens in the background during service updates
Fixes existing issue: Resolves the problem where manually deleted webhooks cannot be recovered
API change
database schema change
upgrade assistant change
change in non-functional attributes such as efficiency or availability
fix of a previous issue