Set the provider in the documented webhook activation statement - #377
Merged
Conversation
Activation is operator-only, so the guide's UPDATE is the procedure, and it only did half of it: the gateway matches on git URL, secret, and provider agreeing with the delivery, and the statement left provider NULL. Every delivery was refused, for both providers, with no symptom beyond scans never starting. Nothing in product code writes that column, so any deployment that followed the page is in this state. The test reads the statement out of the page rather than restating it, runs it, and asks the gateway's own lookup. A copy here would be a second thing to keep right while the operator pastes the one on the page.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Webhook activation is operator-only in this release. The guide says so plainly and hands out an
UPDATEfor the operator to run, which makes that statement part of the product rather than an illustration.It did half the job. It set
webhook_secretand leftwebhook_providerNULL, and the gateway finds a project by its git URL, its secret being set, and its provider agreeing with the kind of delivery that arrived, so one provider's secret cannot be replayed against the other. A row with a secret and no provider matches nothing.So an operator followed the page, believed the webhook was on, and every delivery was refused. For GitHub and GitLab alike. The only symptom is that scans never start, which reads as a scanning problem rather than a configuration one, and there is nothing to find because the configuration is exactly what the page asked for. Nothing in product code writes that column, so this is the state of every deployment that followed the page.
Measured before writing anything: running the documented statement and then calling the gateway's own lookup returns no match for either provider.
The statement now sets both columns and returns both. The test reads it out of the page by its docs-uat id, runs it against a fresh project, and asks
_find_project_by_git_urlwhether the project is now found. Restoring the old statement fails it for both providers. Reading the SQL from the document rather than restating it here is deliberate: a copy in the test is a second thing to keep right, and the one that matters is the one an operator pastes.The two mirrors are compared as well, because a Korean-speaking operator following a different procedure is the same defect in a second place.
Found while investigating GitLab MR comments, which wanted to branch on
webhook_providerand turned out to be reading a column nothing sets. That work now waits on this: with the column actually populated, the validation it needs has something to validate against.