forgejo-federation/templates/repo/settings/webhook/history.tmpl

89 lines
4 KiB
Go HTML Template
Raw Normal View History

{{$isNew:=or .PageIsSettingsHooksNew .PageIsAdminDefaultHooksNew .PageIsAdminSystemHooksNew}}
2015-08-26 22:00:06 +05:30
{{if .PageIsSettingsHooksEdit}}
<h4 class="ui top attached header">
{{ctx.Locale.Tr "repo.settings.recent_deliveries"}}
{{if .Permission.IsAdmin}}
<div class="ui right">
<!-- the button is wrapped with a span because the tooltip doesn't show on hover if we put data-tooltip-content directly on the button -->
<span data-tooltip-content="{{if or $isNew .Webhook.IsActive}}{{ctx.Locale.Tr "repo.settings.webhook.test_delivery_desc"}}{{else}}{{ctx.Locale.Tr "repo.settings.webhook.test_delivery_desc_disabled"}}{{end}}">
<button class="ui teal tiny button{{if not (or $isNew .Webhook.IsActive)}} disabled{{end}}" id="test-delivery" data-link="{{.Link}}/test" data-redirect="{{.Link}}">{{ctx.Locale.Tr "repo.settings.webhook.test_delivery"}}</button>
</span>
2015-08-27 20:36:14 +05:30
</div>
{{end}}
</h4>
2017-04-07 20:20:40 +05:30
<div class="ui attached segment">
<div class="ui list">
{{range .History}}
<div class="item">
<div class="flex-text-block gt-sb">
<div class="flex-text-inline">
{{if .IsSucceed}}
<span class="text green">{{svg "octicon-check"}}</span>
Store webhook event in database (#29145) Refactor the webhook logic, to have the type-dependent processing happen only in one place. --- 1. An event happens 2. It is pre-processed (depending on the webhook type) and its body is added to a task queue 3. When the task is processed, some more logic (depending on the webhook type as well) is applied to make an HTTP request This means that webhook-type dependant logic is needed in step 2 and 3. This is cumbersome and brittle to maintain. Updated webhook flow with this PR: 1. An event happens 2. It is stored as-is and added to a task queue 3. When the task is processed, the event is processed (depending on the webhook type) to make an HTTP request So the only webhook-type dependent logic happens in one place (step 3) which should be much more robust. - the raw event must be stored in the hooktask (until now, the pre-processed body was stored) - to ensure that previous hooktasks are correctly sent, a `payload_version` is added (version 1: the body has already been pre-process / version 2: the body is the raw event) So future webhook additions will only have to deal with creating an http.Request based on the raw event (no need to adjust the code in multiple places, like currently). Moreover since this processing happens when fetching from the task queue, it ensures that the queuing of new events (upon a `git push` for instance) does not get slowed down by a slow webhook. As a concrete example, the PR #19307 for custom webhooks, should be substantially smaller: - no need to change `services/webhook/deliver.go` - minimal change in `services/webhook/webhook.go` (add the new webhook to the map) - no need to change all the individual webhook files (since with this refactor the `*webhook_model.Webhook` is provided as argument) (cherry picked from commit 26653b196bd1d15c532af41f60351596dd4330bd) Conflicts: services/webhook/deliver_test.go trivial context conflict
2024-03-08 03:48:38 +05:30
{{else if not .IsDelivered}}
<span class="text orange">{{svg "octicon-stopwatch"}}</span>
{{else}}
<span class="text red">{{svg "octicon-alert"}}</span>
{{end}}
<a class="ui primary sha label toggle button show-panel" data-panel="#info-{{.ID}}">{{.UUID}}</a>
</div>
<span class="text grey">
2023-09-25 18:12:40 +05:30
{{TimeSince .Delivered.AsTime ctx.Locale}}
</span>
</div>
<div class="info gt-hidden" id="info-{{.ID}}">
<div class="ui top attached tabular menu">
<a class="item active" data-tab="request-{{.ID}}">{{ctx.Locale.Tr "repo.settings.webhook.request"}}</a>
<a class="item" data-tab="response-{{.ID}}">
{{ctx.Locale.Tr "repo.settings.webhook.response"}}
{{if .ResponseInfo}}
{{if .IsSucceed}}
<span class="ui green label">{{.ResponseInfo.Status}}</span>
{{else}}
<span class="ui red label">{{.ResponseInfo.Status}}</span>
{{end}}
{{else}}
<span class="ui label">-</span>
{{end}}
</a>
{{if or $.Permission.IsAdmin $.IsOrganizationOwner $.PageIsAdmin $.PageIsUserSettings}}
2022-01-06 02:30:20 +05:30
<div class="right menu">
<form class="item" action="{{$.Link}}/replay/{{.UUID}}" method="post">
{{$.CsrfTokenHtml}}
<span data-tooltip-content="{{if $.Webhook.IsActive}}{{ctx.Locale.Tr "repo.settings.webhook.replay.description"}}{{else}}{{ctx.Locale.Tr "repo.settings.webhook.replay.description_disabled"}}{{end}}">
<button class="ui tiny button{{if not $.Webhook.IsActive}} disabled{{end}}">{{svg "octicon-sync"}}</button>
</span>
2022-01-06 02:30:20 +05:30
</form>
</div>
{{end}}
</div>
<div class="ui bottom attached tab segment active" data-tab="request-{{.ID}}">
{{if .RequestInfo}}
<h5>{{ctx.Locale.Tr "repo.settings.webhook.headers"}}</h5>
<pre class="webhook-info"><strong>Request URL:</strong> {{.RequestInfo.URL}}
<strong>Request method:</strong> {{if .RequestInfo.HTTPMethod}}{{.RequestInfo.HTTPMethod}}{{else}}POST{{end}}
{{range $key, $val := .RequestInfo.Headers}}<strong>{{$key}}:</strong> {{$val}}
2015-08-27 20:36:14 +05:30
{{end}}</pre>
<h5>{{ctx.Locale.Tr "repo.settings.webhook.payload"}}</h5>
Store webhook event in database (#29145) Refactor the webhook logic, to have the type-dependent processing happen only in one place. --- 1. An event happens 2. It is pre-processed (depending on the webhook type) and its body is added to a task queue 3. When the task is processed, some more logic (depending on the webhook type as well) is applied to make an HTTP request This means that webhook-type dependant logic is needed in step 2 and 3. This is cumbersome and brittle to maintain. Updated webhook flow with this PR: 1. An event happens 2. It is stored as-is and added to a task queue 3. When the task is processed, the event is processed (depending on the webhook type) to make an HTTP request So the only webhook-type dependent logic happens in one place (step 3) which should be much more robust. - the raw event must be stored in the hooktask (until now, the pre-processed body was stored) - to ensure that previous hooktasks are correctly sent, a `payload_version` is added (version 1: the body has already been pre-process / version 2: the body is the raw event) So future webhook additions will only have to deal with creating an http.Request based on the raw event (no need to adjust the code in multiple places, like currently). Moreover since this processing happens when fetching from the task queue, it ensures that the queuing of new events (upon a `git push` for instance) does not get slowed down by a slow webhook. As a concrete example, the PR #19307 for custom webhooks, should be substantially smaller: - no need to change `services/webhook/deliver.go` - minimal change in `services/webhook/webhook.go` (add the new webhook to the map) - no need to change all the individual webhook files (since with this refactor the `*webhook_model.Webhook` is provided as argument) (cherry picked from commit 26653b196bd1d15c532af41f60351596dd4330bd) Conflicts: services/webhook/deliver_test.go trivial context conflict
2024-03-08 03:48:38 +05:30
<pre class="webhook-info"><code class="json">{{or .RequestInfo.Body .PayloadContent}}</code></pre>
{{else}}
-
{{end}}
</div>
<div class="ui bottom attached tab segment" data-tab="response-{{.ID}}">
{{if .ResponseInfo}}
<h5>{{ctx.Locale.Tr "repo.settings.webhook.headers"}}</h5>
<pre class="webhook-info">{{range $key, $val := .ResponseInfo.Headers}}<strong>{{$key}}:</strong> {{$val}}
2015-08-27 20:36:14 +05:30
{{end}}</pre>
<h5>{{ctx.Locale.Tr "repo.settings.webhook.body"}}</h5>
<pre class="webhook-info"><code>{{.ResponseInfo.Body}}</code></pre>
{{else}}
-
{{end}}
</div>
</div>
2015-08-27 20:36:14 +05:30
</div>
{{end}}
2015-08-27 20:36:14 +05:30
</div>
</div>
{{end}}