mirror
/
gitea
mirror of https://github.com/go-gitea/gitea
2
0
Fork 0
Code Issues Releases Wiki Activity
Git with a cup of tea, painless self-hosted git service Mirror for internal git.with.parts use https://git.with.parts
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
15155 Commits
17 Branches
214 Tags
5.0 GiB
Tag: Branch: Tree: 476a043a5f
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '476a043a5f'
${ noResults }
gitea/templates/admin/stacktrace.tmpl

33 lines
1.1 KiB
Raw Normal View History Unescape

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>
3 years ago
{{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
2 years ago
<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>
3 years ago
{{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
2 years ago
{{.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>
3 years ago
<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
2 years ago
<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>
3 years ago
</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>
2 years ago
<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
2 years ago
{{.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>
3 years ago
</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
2 years ago
<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>
3 years ago
</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>
2 years ago
{{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>
3 years ago
</div>
{{template "base/footer" .}}