Webhook for Wiki changes

[f0086]

Add support for triggering webhook notifications on wiki changes.

This PR contains frontend and backend for webhook notifications on wiki actions (create a new page, rename a page, edit a page and delete a page). The frontend got a new checkbox under the Custom Event -> Repository Events section. There is only one checkbox for create/edit/rename/delete actions, because it makes no sense to separate it and others like releases or packages follow the same schema.

The actions itself are separated, so that different notifications will be executed (with the "action" field). All the webhook receivers implement the new interface method (Wiki) and the corresponding tests.

When implementing this, I encounter a little bug on editing a wiki page. Creating and editing a wiki page is technically the same action and will be handled by the updateWikiPage function. But the function need to know if it is a new wiki page or just a change. This distinction is done by the action parameter, but this will not be sent by the frontend (on form submit). This PR will fix this by adding the action parameter with the values _new or _edit, which will be used by the updateWikiPage function.

I've done integration tests with matrix and gitea (http).

This closes #16457

[f0086]

Are there any feedback on this? Is there something I can do to bring this forward?

[lunny]

How close are these webhooks to GH's? If we can keep compatible, that's better.

[f0086]

How close are these webhooks to GH's? If we can keep compatible, that's better.

I am not sure if I got you right. The webhooks have no connection to GitHub. GitHub has a similar feature, to trigger a webhook on events. One of these events are "Wiki" (Wiki page updated.), which is the same what I implemented on Gitea (one webhook for "wiki", which will be triggered on all wiki related events).

So If I got your question right, the wiki webhook are very close to the one GitHub implemented it. Not sure about compatibility. Webhooks will not (yet) migrated by the migrate/mirror tool in Gitea, right?

[f0086]

Is there anything I can do to process this further? Any open questions @lunny ?

[lunny]

Is there anything I can do to process this further?

Any open questions @lunny ?

Maybe we need a rename event?

[lafriks]

How close are these webhooks to GH's? If we can keep compatible, that's better.

I am not sure if I got you right. The webhooks have no connection to GitHub. GitHub has a similar feature, to trigger a webhook on events. One of these events are "Wiki" (Wiki page updated.), which is the same what I implemented on Gitea (one webhook for "wiki", which will be triggered on all wiki related events).

So If I got your question right, the wiki webhook are very close to the one GitHub implemented it. Not sure about compatibility. Webhooks will not (yet) migrated by the migrate/mirror tool in Gitea, right?

Not migration but compared with GitHub what does it send in webhook for wiki events (action and other data)?

[f0086]

I've checked the GitHub webhooks for wiki changes. The following event got triggered when the "[x] Wiki" Checkbox is checked on the Webhook events:

    "pages": [
        {
            "page_name": "RENAMED-TITLE",
            "title": "RENAMED TITLE",
            "summary": null,
            "action": "edited",
            "sha": "41cb79e35438101509f419f5de20711e37d6a57d",
            "html_url": "https://github.com/f0086/webhook-test/wiki/RENAMED-TITLE"
        }
    ],

... where action is "created" on new pages and "edited" for page edits and page renames. Deletion of pages will NOT be triggered at all.

In my implementation, I provide the following information:

• Page (name of the page)
• Comment (an optional comment (commit message))
• Action (created, edited, deleted)
• Sender (User which makes the change)
• Repository (Repo in which the wiki is part of)

So, it differs just in that regard that this implementation will send a deleted action and GitHub ignores it. I call this an improvement over the GitHub version. Page edits and renames are "edit"s too. Besides that, I provide some additional information which makes sense in the Gitea environment (Sender and Repository), the rest is identical to GitHub.

[lunny]

Could we use Doer instead of Sender? Keep compatible with Github will make some tools changes easier.

[f0086]

Could we use Doer instead of Sender? Keep compatible with Github will make some tools changes easier.

For the Payload Struct, it is always Sender (see here), for all other places, I use indeed Doer all the way down, (see here or here or here).

[f0086]

Another week passed away. Are there anything I can do to move this forward @lunny @lafriks ?

[lunny]

Another week passed away. Are there anything I can do to move this forward @lunny @lafriks ?

I will finish the review this week.

[f0086]

Another 2 weeks have passed after the approval. @lafriks can you have a look on this as well? Need a second reviewer here :/

[zeripath]

make lgtm work