Resend webhook payloads from everywhere the result is displayed #8893

New Issue

GiteaMirror · 2025-11-02T08:22:16-06:00

GiteaMirror commented

2025-11-02 08:22:16 -06:00

Originally created by @McNetic on GitHub (May 1, 2022).

Feature Description

While it is possible to resend webhooks from the webhook configuration page, it is not very convenient. If a build fails for technical reasons (timeout, build server problems, dependency problems or whatever that has not to be fixed by fixing the code itself, it would be very helpful if it could be triggered again from where the result is display (be it the commit history or pull request). Especially, since the build may have failed while the webhook itself is succesful, so it is very complicated to find the correct one from the recent deliveries.

Screenshots

No response

Originally created by @McNetic on GitHub (May 1, 2022). ### Feature Description While it is possible to resend webhooks from the webhook configuration page, it is not very convenient. If a build fails for technical reasons (timeout, build server problems, dependency problems or whatever that has not to be fixed by fixing the code itself, it would be very helpful if it could be triggered again from where the result is display (be it the commit history or pull request). Especially, since the build may have failed while the webhook itself is succesful, so it is very complicated to find the correct one from the recent deliveries. ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:22:16 -06:00

GiteaMirror closed this issue

2025-11-02 08:22:16 -06:00

GiteaMirror commented

2025-11-02 08:22:17 -06:00

@techknowlogick commented on GitHub (May 2, 2022):

Webhooks != Statuses on commits. You can set statuses on commits without even needing a webhook active on a repo.

@techknowlogick commented on GitHub (May 2, 2022): Webhooks != Statuses on commits. You can set statuses on commits without even needing a webhook active on a repo.

GiteaMirror commented

2025-11-02 08:22:17 -06:00

@McNetic commented on GitHub (May 2, 2022):

Webhooks != Statuses on commits. You can set statuses on commits without even needing a webhook active on a repo.

I don't see how this relates to the feature request. Everywhere the webhook result is displayed, there is also a link to the "Details". I don't see why it should not be possible to add a replay button. Could you please elaborate and/or reopen the issue?

@McNetic commented on GitHub (May 2, 2022): > Webhooks != Statuses on commits. You can set statuses on commits without even needing a webhook active on a repo. I don't see how this relates to the feature request. Everywhere the webhook result is displayed, there is also a link to the "Details". I don't see why it should not be possible to add a replay button. Could you please elaborate and/or reopen the issue?

GiteaMirror commented

2025-11-02 08:22:17 -06:00

@McNetic commented on GitHub (May 16, 2022):

It would be very nice if you could explain why this is not a valid feature request.

@McNetic commented on GitHub (May 16, 2022): It would be very nice if you could explain why this is not a valid feature request.

GiteaMirror commented

2025-11-02 08:22:18 -06:00

@lunny commented on GitHub (May 16, 2022):

Because you don't know the commit statuses come from which webhook or a cron task. At least you cannot track that both in Github and Gitea.

@lunny commented on GitHub (May 16, 2022): Because you don't know the commit statuses come from which webhook or a cron task. At least you cannot track that both in Github and Gitea.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#8893