forks/forgejo
1
0
Fork 0
Code Releases Activity
forgejo/templates/admin/stacktrace.tmpl

33 lines
1.1 KiB
Handlebars
Raw Normal View History

Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
{{template "base/head" .}}
Add main landmark to templates and adjust titles (#22670) * Add main aria landmark to templates * Adjust some titles to improve understanding of location in navigation Contributed by @Forgejo
2023-02-01 17:56:10 -05:00
<div role="main" aria-label="{{.Title}}" class="page-content admin monitor">
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
{{template "admin/navbar" .}}
<div class="ui container">
{{template "base/alert" .}}
<h4 class="ui top attached header">
Refactor `i18n` to `locale` (#20153) * Refactor `i18n` to `locale` - Currently we're using the `i18n` variable naming for the `locale` struct. This contains locale's specific information and cannot be used for general i18n purpose, therefore refactoring it to `locale` makes more sense. - Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200 * Update routers/install/install.go
2022-06-27 16:58:46 -04:00
{{.locale.Tr "admin.monitor.stacktrace"}}: {{.locale.Tr "admin.monitor.goroutines" .GoroutineCount}}
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
<div class="ui right">
Refactor `i18n` to `locale` (#20153) * Refactor `i18n` to `locale` - Currently we're using the `i18n` variable naming for the `locale` struct. This contains locale's specific information and cannot be used for general i18n purpose, therefore refactoring it to `locale` makes more sense. - Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200 * Update routers/install/install.go
2022-06-27 16:58:46 -04:00
<a class="ui primary tiny button" href="{{AppSubUrl}}/admin/monitor">{{.locale.Tr "admin.monitor"}}</a>
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
</div>
</h4>
<div class="ui attached segment">
<div class="ui relaxed divided list">
{{range .ProcessStacks}}
{{template "admin/stacktrace-row" dict "Process" . "root" $}}
{{end}}
</div>
</div>
</div>
</div>
Refactor delete_modal_actions template and use it for project column related actions (#24097) Co-Author: @wxiaoguang This PR is to fix https://github.com/go-gitea/gitea/issues/23318#issuecomment-1506275446 . The way to fix this in this PR is to use `delete_modal_actions.tmpl` here both to fix this issue and keep ui consistency (as suggested by [TODO here](https://github.com/go-gitea/gitea/blob/4299c3b7db61f8741eca0ba3d663bb65745a4acc/templates/projects/view.tmpl#L161)) And this PR also refactors `delete_modal_actions.tmpl` and its related styles, and use the template for more modal actions: 1. Added template attributes: * locale * ModalButtonStyle: "yes" (default) or "confirm" * ModalButtonCancelText * ModalButtonOkText 2. Rename `delete_modal_actions.tmpl` template to `modal_actions_confirm.tmpl` because it is not only used for action modals deletion now. 3. Refactored css related to modals into `web_src/css/modules/modal.css` and improved the styles. 4. Also use the template for PR deletion modal and remove issue dependency modal. 5. Some modals should also use the template, but not sure how to open them, so mark these modal actions by `{{/* TODO: Convert to base/modal_actions_confirm */}}` After (Also tested on arc green): Hovering on the left buttons <img width="711" alt="Screen Shot 2023-04-23 at 15 17 12" src="https://user-images.githubusercontent.com/17645053/233825650-76307e65-9255-44bb-80e8-7062f58ead1b.png"> <img width="786" alt="Screen Shot 2023-04-23 at 15 17 21" src="https://user-images.githubusercontent.com/17645053/233825652-4dc6f7d1-a180-49fb-a468-d60950eaee0d.png"> Test for functionalities: https://user-images.githubusercontent.com/17645053/233826857-76376fda-022c-42d0-b0f3-339c17ca4e59.mov --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2023-04-23 05:24:19 -04:00
<div class="ui gitea-confirm-modal delete modal">
<div class="header">
Refactor `i18n` to `locale` (#20153) * Refactor `i18n` to `locale` - Currently we're using the `i18n` variable naming for the `locale` struct. This contains locale's specific information and cannot be used for general i18n purpose, therefore refactoring it to `locale` makes more sense. - Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200 * Update routers/install/install.go
2022-06-27 16:58:46 -04:00
{{.locale.Tr "admin.monitor.process.cancel"}}
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
</div>
<div class="content">
Refactor `i18n` to `locale` (#20153) * Refactor `i18n` to `locale` - Currently we're using the `i18n` variable naming for the `locale` struct. This contains locale's specific information and cannot be used for general i18n purpose, therefore refactoring it to `locale` makes more sense. - Ref: https://github.com/go-gitea/gitea/pull/20096#discussion_r906699200 * Update routers/install/install.go
2022-06-27 16:58:46 -04:00
<p>{{$.locale.Tr "admin.monitor.process.cancel_notices" `<span class="name"></span>` | Safe}}</p>
<p>{{$.locale.Tr "admin.monitor.process.cancel_desc"}}</p>
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
</div>
Refactor delete_modal_actions template and use it for project column related actions (#24097) Co-Author: @wxiaoguang This PR is to fix https://github.com/go-gitea/gitea/issues/23318#issuecomment-1506275446 . The way to fix this in this PR is to use `delete_modal_actions.tmpl` here both to fix this issue and keep ui consistency (as suggested by [TODO here](https://github.com/go-gitea/gitea/blob/4299c3b7db61f8741eca0ba3d663bb65745a4acc/templates/projects/view.tmpl#L161)) And this PR also refactors `delete_modal_actions.tmpl` and its related styles, and use the template for more modal actions: 1. Added template attributes: * locale * ModalButtonStyle: "yes" (default) or "confirm" * ModalButtonCancelText * ModalButtonOkText 2. Rename `delete_modal_actions.tmpl` template to `modal_actions_confirm.tmpl` because it is not only used for action modals deletion now. 3. Refactored css related to modals into `web_src/css/modules/modal.css` and improved the styles. 4. Also use the template for PR deletion modal and remove issue dependency modal. 5. Some modals should also use the template, but not sure how to open them, so mark these modal actions by `{{/* TODO: Convert to base/modal_actions_confirm */}}` After (Also tested on arc green): Hovering on the left buttons <img width="711" alt="Screen Shot 2023-04-23 at 15 17 12" src="https://user-images.githubusercontent.com/17645053/233825650-76307e65-9255-44bb-80e8-7062f58ead1b.png"> <img width="786" alt="Screen Shot 2023-04-23 at 15 17 21" src="https://user-images.githubusercontent.com/17645053/233825652-4dc6f7d1-a180-49fb-a468-d60950eaee0d.png"> Test for functionalities: https://user-images.githubusercontent.com/17645053/233826857-76376fda-022c-42d0-b0f3-339c17ca4e59.mov --------- Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2023-04-23 05:24:19 -04:00
{{template "base/modal_actions_confirm" .}}
Add Goroutine stack inspector to admin/monitor (#19207) Continues on from #19202. Following the addition of pprof labels we can now more easily understand the relationship between a goroutine and the requests that spawn them. This PR takes advantage of the labels and adds a few others, then provides a mechanism for the monitoring page to query the pprof goroutine profile. The binary profile that results from this profile is immediately piped in to the google library for parsing this and then stack traces are formed for the goroutines. If the goroutine is within a context or has been created from a goroutine within a process context it will acquire the process description labels for that process. The goroutines are mapped with there associate pids and any that do not have an associated pid are placed in a group at the bottom as unbound. In this way we should be able to more easily examine goroutines that have been stuck. A manager command `gitea manager processes` is also provided that can export the processes (with or without stacktraces) to the command line. Signed-off-by: Andrew Thornton <art27@cantab.net>
2022-03-31 13:01:43 -04:00
</div>
{{template "base/footer" .}}
Copy permalink