#7361 - feat(ui): Automatically refresh workflows in the "Actions" list - forgejo/forgejo - Codeberg.org
forgejo
forgejo
Fork
You've already forked forgejo
738
Code
Issues
1.3k
Pull requests
155
Projects
Releases
100
Packages
Activity
Actions
84
feat(ui): Automatically refresh workflows in the "Actions" list
#7361
Merged
Gusted
merged 10 commits from
mfenniak/forgejo:dynrefresh-actions-list
into
forgejo
2025-04-04 16:39:01 +02:00
Conversation
11
Commits
10
Files changed
+270
-98
mfenniak
commented
2025-03-28 02:43:50 +01:00
Member
Copy link
This PR makes the "Actions" list (eg.
) dynamically refresh using htmx and partial page reloading. This addresses a pet peeve as I find it common to end up on this page and have workflows in-progress, but not be able to monitor the workflows to success or failure from the page as it currently doesn't do any data refreshing.
The major risks of this change are:
Increased server-side load & network utilization. In order to mitigate this risk, I have configured the refresh to occur every 30 seconds
only
when the Page Visibility API indicates that the web page is currently visible to the end-user. It is still reasonable to assume this change will increase server-side load though.
UI interactions on the page, such as the "Actor" and "Status" dropdown and the workflow dispatch form, would be replaced from the server with non-expanded UI during the refresh. This problem is prevented by stopping the refresh while these UIs are in their expanded states.
I'm really uncertain if this is the way that Forgejo's UI development would proceed to add this kind of dynamic refresh. If there's a different approach preferred, would be happy to collaborate on the right direction.
Checklist
The
contributor guide
contains information that will be helpful to first time contributors. There also are a few
conditions for merging Pull Requests in Forgejo repositories
. You are also welcome to join the
Forgejo development chatroom
Tests
I added test coverage for Go changes...
I added test coverage for JavaScript changes...
Documentation
I created a pull request
to the documentation
to explain to Forgejo users how to use this change.
I did not document these changes and I do not expect someone else to do it.
Release notes
I do not want this change to show in the release notes.
I want the title to show in the release notes with a link to this pull request.
I want the content of the
release-notes/
to be be used for the release notes instead of the title.
Release notes
User Interface features
PR
: feat(ui): Automatically refresh workflows in the "Actions" list
This PR makes the "Actions" list (eg. https://codeberg.org/forgejo/forgejo/actions) dynamically refresh using htmx and partial page reloading. This addresses a pet peeve as I find it common to end up on this page and have workflows in-progress, but not be able to monitor the workflows to success or failure from the page as it currently doesn't do any data refreshing.
The major risks of this change are:
- Increased server-side load & network utilization. In order to mitigate this risk, I have configured the refresh to occur every 30 seconds **only** when the Page Visibility API indicates that the web page is currently visible to the end-user. It is still reasonable to assume this change will increase server-side load though.
- UI interactions on the page, such as the "Actor" and "Status" dropdown and the workflow dispatch form, would be replaced from the server with non-expanded UI during the refresh. This problem is prevented by stopping the refresh while these UIs are in their expanded states.
I'm really uncertain if this is the way that Forgejo's UI development would proceed to add this kind of dynamic refresh. If there's a different approach preferred, would be happy to collaborate on the right direction.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org).
### Tests
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [x] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)).
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- [x] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] I do not want this change to show in the release notes.
- [x] I want the title to show in the release notes with a link to this pull request.
- [ ] I want the content of the `release-notes/
## Release notes
- User Interface features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/7361): feat(ui): Automatically refresh workflows in the "Actions" list
❤️
mfenniak
added the
test
needed
label
2025-03-28 02:43:50 +01:00
mfenniak
requested reviews from
caesar
crystal
Gusted
2025-03-28 02:43:53 +01:00
earl-warren
requested reviews from
UI
and removed review requests for
caesar
crystal
2025-03-28 09:18:16 +01:00
earl-warren
commented
2025-03-28 09:21:37 +01:00
Contributor
Copy link
I would very much welcome this improvement, so
When displaying an individual action log the refresh rate is higher so I would not worry about server load too much. 30 seconds seems fine.
Regarding the UI side of it I can't comment as my skills in that area are non-existent but I pinged
@forgejo/UI
I would very much welcome this improvement, so 👍 When displaying an individual action log the refresh rate is higher so I would not worry about server load too much. 30 seconds seems fine.
Regarding the UI side of it I can't comment as my skills in that area are non-existent but I pinged @forgejo/UI
Gusted
added the
forgejo/ui
label
2025-03-28 15:23:04 +01:00
mfenniak
added
test
present
and removed
test
needed
labels
2025-03-28 16:50:48 +01:00
mfenniak
commented
2025-03-28 16:52:44 +01:00
Author
Member
Copy link
Testing added. The scope of the test is somewhat narrow, but it seems appropriate considering the small nature of this change to not boil the ocean over the details in an e2e test.
Testing added. The scope of the test is somewhat narrow, but it seems appropriate considering the small nature of this change to not boil the ocean over the details in an e2e test.
Gusted
commented
2025-03-28 23:56:50 +01:00
Owner
Copy link
Is there any javascript run for the elements that get morphed? E.g. attaching event listeners. They need extra checking that the morphing preserves them, otherwise I think the current approach is fine, it's an
easier
target than the other HTMX parts in Forgejo.
Is there any javascript run for the elements that get morphed? E.g. attaching event listeners. They need extra checking that the morphing preserves them, otherwise I think the current approach is fine, it's an _easier_ target than the other HTMX parts in Forgejo.
fnetX
commented
2025-03-29 00:53:06 +01:00
Owner
Copy link
UI interactions on the page, such as the "Actor" and "Status" dropdown and the workflow dispatch form, would be replaced from the server with non-expanded UI during the refresh. This problem is prevented by stopping the refresh while these UIs are in their expanded states.
Why do you replace them at all? Wouldn't it be possible to only replace the resulting list?
> UI interactions on the page, such as the "Actor" and "Status" dropdown and the workflow dispatch form, would be replaced from the server with non-expanded UI during the refresh. This problem is prevented by stopping the refresh while these UIs are in their expanded states.
Why do you replace them at all? Wouldn't it be possible to only replace the resulting list?
mfenniak
commented
2025-03-29 01:36:23 +01:00
Author
Member
Copy link
@Gusted
The only event listeners that I have been able to find present are on the drop-downs, which experimentally remain functional after the morph.
Why do you replace them at all? Wouldn't it be possible to only replace the resulting list?
@fnetX
The options in the Actors list can change as new workflows are executed. Refreshing the Actors list isn't really critical UI functionality and could be excluded, but, this also includes changing from the drop-down not being present at all -- if the page is initially loaded as "There are no workflows yet." the auto-refresh is still active.
I did consider doing the refresh at lower levels, even down to just refreshing workflows that were already running. But that had the downside of not showing new workflows, and the timestamps on the right-hand-side would be messed up by just being kinda up-to-date for some items. So this led me to the full-list refresh, which led me to including the Actor drop-down because it's only rendered when there are items, and plus its data is dynamic. Seemed like the right place to land to me.
@Gusted The only event listeners that I have been able to find present are on the drop-downs, which experimentally remain functional after the morph.
> Why do you replace them at all? Wouldn't it be possible to only replace the resulting list?
@fnetX The options in the Actors list can change as new workflows are executed. Refreshing the Actors list isn't really critical UI functionality and could be excluded, but, this also includes changing from the drop-down not being present at all -- if the page is initially loaded as "There are no workflows yet." the auto-refresh is still active.
I did consider doing the refresh at lower levels, even down to just refreshing workflows that were already running. But that had the downside of not showing new workflows, and the timestamps on the right-hand-side would be messed up by just being kinda up-to-date for some items. So this led me to the full-list refresh, which led me to including the Actor drop-down because it's only rendered when there are items, and plus its data is dynamic. Seemed like the right place to land to me.
Gusted
commented
2025-03-29 19:27:28 +01:00
Owner
Copy link
@mfenniak
wrote in
#7361 (comment)
The only event listeners that I have been able to find present are on the drop-downs, which experimentally remain functional after the morph.
Great, thank you. Are these covered under E2E testing? The experience with other event listeners learns that that future version of the morph library might break them (it's the reason why we are on a old version of idiomorph).
@mfenniak wrote in https://codeberg.org/forgejo/forgejo/pulls/7361#issuecomment-3138335:
> The only event listeners that I have been able to find present are on the drop-downs, which experimentally remain functional after the morph.
Great, thank you. Are these covered under E2E testing? The experience with other event listeners learns that that future version of the morph library might break them (it's the reason why we are on a old version of idiomorph).
mfenniak
commented
2025-03-30 01:42:00 +01:00
Author
Member
Copy link
@Gusted
Great feedback. I hadn't included those in the E2E tests because I didn't have a great way to simulate the polling interval and didn't want to write tests that waited >30s. Based upon your feedback that the risks are higher than I initially assumed, I've added test cases that cover testing all the interactive elements during a refresh (to ensure they aren't interrupted) and after a refresh (to ensure event handlers work correctly).
The caveat to these additional tests is that they use a simulated polling event so that the tests don't need to wait for the 30s interval. I don't love having a testing hook in frontend code for an e2e test, but htmx doesn't seem to provide any other mechanism and its purpose is documented for future archeologists (
).
@Gusted Great feedback. I hadn't included those in the E2E tests because I didn't have a great way to simulate the polling interval and didn't want to write tests that waited >30s. Based upon your feedback that the risks are higher than I initially assumed, I've added test cases that cover testing all the interactive elements during a refresh (to ensure they aren't interrupted) and after a refresh (to ensure event handlers work correctly).
The caveat to these additional tests is that they use a simulated polling event so that the tests don't need to wait for the 30s interval. I don't love having a testing hook in frontend code for an e2e test, but htmx doesn't seem to provide any other mechanism and its purpose is documented for future archeologists (😉).
Gusted
reviewed
2025-03-30 13:54:29 +02:00
tests/e2e/actions.test.e2e.ts
Outdated
@ -14,2 +14,4 @@
const
workflow_trigger_notification_text
'This workflow has a workflow_dispatch event trigger.'
async
function
dispatchSuccess
page
testInfo
Gusted
commented
2025-03-30 13:46:30 +02:00
Owner
Copy link
Same for the type here, should be something like
page: Page, testInfo: TestInfo
Same for the type here, should be something like `page: Page, testInfo: TestInfo`
mfenniak
marked this conversation as resolved
tests/e2e/actions.test.e2e.ts
Outdated
@ -74,2 +81,4 @@
await
save_visual
page
async
function
simulatePollingInterval
page
Gusted
commented
2025-03-30 13:46:08 +02:00
Owner
Copy link
Could you add a type here? it should be something like
page: Page
and the import for
@playwright/test
should look like:
import
expect
type
Page
from
'@playwright/test'
Could you add a type here? it should be something like `page: Page` and the import for `@playwright/test` should look like:
```ts
import {expect, type Page} from '@playwright/test';
```
mfenniak
marked this conversation as resolved
tests/e2e/actions.test.e2e.ts
Outdated
@ -76,0 +88,4 @@
// No other way to trigger a client-side event other than using browser-side eval:
// eslint-disable-next-line playwright/no-eval
await
page
$eval
'html'
Gusted
commented
2025-03-30 13:53:19 +02:00
Owner
Copy link
It seems like the following also works and avoids the usage of eval:
await
page
evaluate
(()
=>
document
dispatchEvent
new
Event
'simulate-polling-interval'
));
});
It seems like the following also works and avoids the usage of eval:
```ts
await page.evaluate(() => {
document.dispatchEvent(new Event('simulate-polling-interval'));
});
```
mfenniak
commented
2025-03-30 23:58:27 +02:00
Author
Member
Copy link
I've adapted the same for the
changevisibility
event, removing the need for the eslint ignore. Thanks.
👍 I've adapted the same for the `changevisibility` event, removing the need for the eslint ignore. Thanks.
mfenniak
marked this conversation as resolved
tests/e2e/actions.test.e2e.ts
Outdated
@ -76,0 +102,4 @@
// mimic a user returning to the tab on their browser, which should trigger the workflow list to refresh and display
// the newly dispatched workflow from the other page.
const
backgroundPage
await
await
page
context
newPage
Gusted
commented
2025-03-30 13:45:06 +02:00
Owner
Copy link
Can be simplified to:
await
page
context
().
newPage
();
Can be simplified to:
```ts
await page.context().newPage();
```
mfenniak
marked this conversation as resolved
tests/e2e/actions.test.e2e.ts
Outdated
@ -76,0 +110,4 @@
// No other way to trigger a visibilitychange event other than using browser-side eval:
// eslint-disable-next-line playwright/no-eval
await
backgroundPage
$eval
'html'
Gusted
commented
2025-03-30 13:49:29 +02:00
Owner
Copy link
Something interesting happens here, the test does not fail if I remove this eval.
Something interesting happens here, the test does not fail if I remove this eval.
mfenniak
commented
2025-03-31 00:00:26 +02:00
Author
Member
Copy link
Good catch -- when multiple tests are run in sequence, the previous tests create workflows that still show "now" as their timestamp, so even if the refresh doesn't occur then the assertions were passing based upon data from the previous test.
I've tightened up the assertions now to retrieve the workflow ID from the primary page's first entry, and check that is present on the secondary page after the refresh. The test no longer passes if the event isn't dispatched.
Good catch -- when multiple tests are run in sequence, the previous tests create workflows that still show "now" as their timestamp, so even if the refresh doesn't occur then the assertions were passing based upon data from the previous test.
I've tightened up the assertions now to retrieve the workflow ID from the primary page's first entry, and check that is present on the secondary page after the refresh. The test no longer passes if the event isn't dispatched.
mfenniak
marked this conversation as resolved
tests/e2e/actions.test.e2e.ts
Outdated
@ -76,0 +122,4 @@
// which triggers a workflow dispatch. After the polling, the page should refresh and show the newly dispatched
// workflow from the other page.
const
backgroundPage
await
await
page
context
newPage
Gusted
commented
2025-03-30 13:49:43 +02:00
Owner
Copy link
Can be simplified to:
await
page
context
().
newPage
();
Can be simplified to:
```ts
await page.context().newPage();
```
mfenniak
marked this conversation as resolved
mfenniak
commented
2025-03-31 00:03:48 +02:00
Author
Member
Copy link
@Gusted
Review comments addressed; thanks!
You'll see one additional change on a re-review: I also discovered that the
refresh does not break interacting with open drop-downs
test could intermittently pass even if the related code was disabled since the test did not wait for the refresh cycle to complete. Wherever any test was performing a refresh, it now uses the new
completeDynamicRefresh
to check that the refresh indicator indicates the operation is complete.
@Gusted Review comments addressed; thanks! 👍
You'll see one additional change on a re-review: I also discovered that the `refresh does not break interacting with open drop-downs` test could intermittently pass even if the related code was disabled since the test did not wait for the refresh cycle to complete. Wherever any test was performing a refresh, it now uses the new `completeDynamicRefresh` to check that the refresh indicator indicates the operation is complete.
Gusted
added the
enhancement/feature
label
2025-04-01 15:29:37 +02:00
Gusted
approved these changes
2025-04-01 15:33:45 +02:00
Gusted
left a comment
Copy link
Thank you, the code and testing LGTM.
Thank you, the code and testing LGTM.
Gusted
force-pushed dynrefresh-actions-list from
ea3143231a
All checks were successful
testing / frontend-checks (pull_request)
Successful in 1m12s
Details
testing / backend-checks (pull_request)
Successful in 3m49s
Details
Integration tests for the release process / release-simulation (pull_request)
Successful in 7m4s
Details
testing / test-unit (pull_request)
Successful in 3m50s
Details
testing / test-e2e (pull_request)
Successful in 4m51s
Details
testing / test-remote-cacher (redis) (pull_request)
Successful in 1m22s
Details
testing / test-remote-cacher (valkey) (pull_request)
Successful in 1m14s
Details
testing / test-remote-cacher (garnet) (pull_request)
Successful in 1m10s
Details
testing / test-remote-cacher (redict) (pull_request)
Successful in 1m12s
Details
testing / test-mysql (pull_request)
Successful in 21m57s
Details
testing / test-sqlite (pull_request)
Successful in 23m5s
Details
testing / test-pgsql (pull_request)
Successful in 26m10s
Details
testing / security-check (pull_request)
Successful in 1m6s
Details
issue-labels / backporting (pull_request_target)
Has been skipped
Details
requirements / merge-conditions (pull_request)
Successful in 4s
Details
issue-labels / cascade (pull_request_target)
Has been skipped
Details
issue-labels / release-notes (pull_request_target)
Has been skipped
Details
to
481dcafa52
All checks were successful
testing / frontend-checks (pull_request)
Successful in 50s
Details
testing / backend-checks (pull_request)
Successful in 2m37s
Details
testing / test-e2e (pull_request)
Successful in 4m10s
Details
testing / test-unit (pull_request)
Successful in 5m49s
Details
testing / test-remote-cacher (valkey) (pull_request)
Successful in 2m6s
Details
testing / test-remote-cacher (redis) (pull_request)
Successful in 2m9s
Details
testing / test-remote-cacher (garnet) (pull_request)
Successful in 2m10s
Details
testing / test-remote-cacher (redict) (pull_request)
Successful in 2m8s
Details
testing / test-mysql (pull_request)
Successful in 18m47s
Details
testing / test-sqlite (pull_request)
Successful in 20m53s
Details
testing / test-pgsql (pull_request)
Successful in 24m31s
Details
testing / security-check (pull_request)
Successful in 1m5s
Details
milestone / set (pull_request_target)
Successful in 4s
Details
issue-labels / backporting (pull_request_target)
Has been skipped
Details
issue-labels / cascade (pull_request_target)
Has been skipped
Details
requirements / merge-conditions (pull_request)
Successful in 2s
Details
issue-labels / release-notes (pull_request_target)
Successful in 37s
Details
2025-04-04 15:49:47 +02:00
Compare
Gusted
scheduled this pull request to auto merge when all checks succeed
2025-04-04 15:53:05 +02:00
Gusted
referenced this pull request from a commit
2025-04-04 16:39:00 +02:00
feat(ui): Automatically refresh workflows in the "Actions" list (#7361)
Gusted
merged commit
6ad706aa88
into
forgejo
2025-04-04 16:39:01 +02:00
forgejo-release-notes-assistant
added this to the
Forgejo v12.0.0
milestone
2025-04-04 16:39:09 +02:00
davrot
referenced this pull request from a commit
2025-06-02 14:13:51 +02:00
feat(ui): Automatically refresh workflows in the "Actions" list (#7361)
Gusted
added the
worth a release-note
label
2025-07-05 19:56:45 +02:00
forgejo-release-notes-assistant
commented
2025-07-05 19:57:58 +02:00
Member
Copy link
Where does that come from?
The following is a preview of the release notes for this pull request, as they will appear in the upcoming release. They are derived from the content of the `release-notes/7361.md` file, if it exists, or the title of the pull request. They were also added at the bottom of the description of this pull request for easier reference.
This message and the release notes originate from a call to the
release-notes-assistant
@@ -31,2 +31,9 @@
- [ ] I want the content of the `release-notes/
+
+## Release notes
+
+- User Interface features
+ - [PR](https://codeberg.org/forgejo/forgejo/pulls/7361): feat(ui): Automatically refresh workflows in the "Actions" list
+
Release notes
User Interface features
PR
: feat(ui): Automatically refresh workflows in the "Actions" listWhere does that come from?
The following is a preview of the release notes for this pull request, as they will appear in the upcoming release. They are derived from the content of the `release-notes/7361.md` file, if it exists, or the title of the pull request. They were also added at the bottom of the description of this pull request for easier reference.
This message and the release notes originate from a call to the [release-notes-assistant](https://code.forgejo.org/forgejo/release-notes-assistant).
```diff
@@ -31,2 +31,9 @@
- [ ] I want the content of the `release-notes/
+
+## Release notes
+
+- User Interface features
+ - [PR](https://codeberg.org/forgejo/forgejo/pulls/7361): feat(ui): Automatically refresh workflows in the "Actions" list
+
```
## Release notes
- User Interface features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/7361): feat(ui): Automatically refresh workflows in the "Actions" list
Gusted
referenced this pull request from forgejo/website
2025-07-05 20:12:43 +02:00
Forgejo v12.0.0 blog post snippets
#608
forgejo-actions
referenced this pull request from forgejo/website
2025-08-11 19:03:56 +02:00
Dead links report
#529
forgejo-actions
referenced this pull request from forgejo/website
2025-11-27 18:11:41 +01:00
Dead links report
#529
forgejo-actions
referenced this pull request from forgejo/website
2025-12-08 18:03:53 +01:00
Dead links report
#529
forgejo-actions
referenced this pull request from forgejo/website
2025-12-18 18:03:25 +01:00
Dead links report
#529
alberic89
referenced this pull request from a commit
2026-02-23 18:42:24 +01:00
feat(ui): Automatically refresh workflows in the "Actions" list (#7361)
to join this conversation.
Reviewers
No reviewers
Gusted
forgejo/UI
Labels
Clear labels
arch
riscv64
Archived
backport/v1.19
Scheduled for backport to Forgejo v1.19
Archived
backport/v1.20
Scheduled for backport to Forgejo v1.20
Archived
backport/v1.21/forgejo
Scheduled for backport to Forgejo v1.21
Archived
backport/v10.0/forgejo
Automated backport to v10.0
Archived
backport/v11.0/forgejo
Automated backport to v11.0
backport/v12.0/forgejo
Automated backport to v12.0
Archived
backport/v13.0/forgejo
Automated backport to v13.0
Archived
backport/v14.0/forgejo
Automated backport to v14.0
backport/v15.0/forgejo
Automated backport to v15.0
backport/v7.0/forgejo
Scheduled for backport to Forgejo v7.0
Archived
backport/v8.0/forgejo
Scheduled for backport to Forgejo v8.0
Archived
backport/v9.0/forgejo
Scheduled for backport to Forgejo v9.0
Archived
breaking
The release containing this change is not backward compatible
bug
Something is not working
Archived
bug
confirmed
it can be reproduced
bug
duplicate
bug has already been reported in the Forgejo tracker
bug
needs-more-info
the information provided does not contain enough details
bug
new-report
bug has just been reported and need triage (default label on issue creation)
bug
reported-upstream
bug cannot be fixed within Forgejo easily, it has been reported upstream
code/actions
Forgejo Actions feature
code/api
API
code/auth
Forgejo Authentication
code/auth/faidp
Forgejo as Identity Provider (in OAuth/OIDC flow)
code/auth/farp
Forgejo as Relying Party / Client (in OAuth/OIDC flow)
code/email
Everything related to email in Forgejo
code/federation
Federation
code/git
Related to the Git backend in Forgejo
code/migrations
Migration between Git forges (i.e. for GitHub, GitLab, Gitea, Forgejo, etc.). NOT for database migrations.
code/packages
Forgejo package and container registry
code/wiki
database
MySQL
database
PostgreSQL
database
SQLite
dependency-upgrade
dependency
Chi
Archived
dependency
Chroma
Archived
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Gitea
Archived
dependency
Golang
Discussion
duplicate
This issue or pull request already exists
enhancement/feature
New feature
forgejo/accessibility
Accessibility (a11y)
forgejo/branding
Branding (logo, name, tagline etc.)
forgejo/ci
Forgejo Actions CI configuration
forgejo/commit-graph
The commit graph feature and page.
forgejo/documentation
forgejo/furnace cleanup
Keeping Forgejo in sync with its dependencies and contributing back to them
Archived
forgejo/i18n
t9n/translation, l10n/localization, and i18n/internationalization of Forgejo
forgejo/interop
Interoperability with other services: Webhooks, bridges, integrations
forgejo/moderation
Moderation
forgejo/privacy
Privacy first
forgejo/release
Release management
forgejo/scaling
Performance and scaling
forgejo/security
Security (please disclose responsibly)
forgejo/ui
User interface
Gain
High
User research provides indicators that this would be good to have, interested contributors are encouraged to pick this.
Gain
Nice to have
This is likely worth having, but the assumption is not backed by user research data (it might benefit a small amount of users only.) Unlikely to receive much attention, but feel free to pick.
Gain
Undefined
Not enough information to assess the request's benefits. This issue may be closed if no gain is established: You can help by giving us more input.
Gain
Very High
User research indicates that this is an important improvement for Forgejo users. Contributions very welcome!
good first issue
Optimal for first-timers! Make sure to look for further explanations and ask for help if needed. If you want, you can consider the person who added this label as a point of contact.
i18n/backport-stable
This PR needs to be backported to stable branch of Forgejo safely and manually, using a migration script.
impact
large
Large impact: Potential data loss, many users affected, major degradation in UX.
impact
medium
Medium impact: Several users affected, degradation in UX, workarounds might be available but inconvenient.
impact
small
Small impact: No data loss, workarounds might be available, affects few users.
impact
unknown
Report was not yet triaged to assess impact.
Incompatible license
This pull request contains changes that are not (yet) compatible with the current Forgejo license
issue
closed
The issue was resolved in the repository of the dependency
issue
do-not-exist-yet
An issue should be created in the respository of the dependency
issue
open
An open issue exists in the upstream repository of the dependency
manual test
Pull requests that have been merged with a manual test
Archived
Manually tested during feature freeze
The manual test instructions were followed
OS
FreeBSD
Specific to the FreeBSD Operating System
OS
Linux
Specific to (GNU/)Linux Operating Systems
OS
macOS
Specific to the MacOS Operating System
OS
Windows
Specific to the Windows Operating System
problem
A user report about a problem. Needs to be triaged to find potential solutions.
QA
regression
found in the version of the milestone and not before
release blocker
Issues that must be fixed before the release can be published
Release Cycle
Feature Freeze
Only bug fixes with automated tests (except for CSS/JavaScript)
release-blocker
v7.0
Issues that must be fixed before Forgejo v7.0 can be released 17 April 2024
Archived
release-blocker
v7.0.1
Issues that must be fixed before Forgejo v7.0.1 can be released
Archived
release-blocker
v7.0.2
Issues that must be fixed before Forgejo v7.0.2 can be released
Archived
release-blocker
v7.0.3
Issues that must be fixed before Forgejo v7.0.3 can be released
Archived
release-blocker
v7.0.4
Issues that must be fixed before Forgejo v7.0.4 can be released
Archived
release-blocker
v8.0.0
Issues that must be fixed before Forgejo v8.0.0 can be released
Archived
release-blocker/v9.0.0
Issues that must be fixed before Forgejo v9.0.0 can be released
Archived
run-all-playwright-tests
Add this label to a PR to run all playwright tests manually.
run-end-to-end-tests
Trigger additional tests on the PR when it is ready to be merged
test
manual
manual testing has been documented
test
needed
test should be added
test
needs-help
help needed to add a test
test
not-needed
no additional test is needed
test
present
test has been added
untested
Pull requests that have been merged with no test and submitted as is to the dependency where they belong
Archived
User research - time-tracker
Time tracking feature for issues and the JS stopwatch.
valuable code
This PR was closed because the implementation is incomplete
worth a release-note
Add this PR to the release notes
User research - Accessibility
Requires input about accessibility features, likely involves user testing.
User research - Blocked
Do not pick as-is! We are happy if you can help, but please coordinate with ongoing redesign in this area.
User research - Community
Community features, such as discovering other people's work or otherwise feeling welcome on a Forgejo instance.
User research - Config (instance)
Instance-wide configuration, authentication and other admin-only needs.
User research - Errors
How to deal with errors in the application and write helpful error messages.
User research - Filters
How filter and search is being worked with.
User research - Future backlog
The issue might be inspiring for future design work.
User research - Git workflow
AGit, fork-based and new Git workflow, PR creation etc
User research - Labels
Active research about Labels
User research - Moderation
Moderation Featuers for Admins are undergoing active User Research
User research - Needs input
Use this label to let the User Research team know their input is requested.
User research - Notifications/Dashboard
Research on how users should know what to do next.
User research - Rendering
Text rendering, markup languages etc
User research - Repo creation
Active research about the New Repo dialog.
User research - Repo units
The repo sections, disabling them and the "Add more" button.
User research - Security
User research - Settings (in-app)
How to structure in-app settings in the future?
No labels
arch
riscv64
backport/v1.19
backport/v1.20
backport/v1.21/forgejo
backport/v10.0/forgejo
backport/v11.0/forgejo
backport/v12.0/forgejo
backport/v13.0/forgejo
backport/v14.0/forgejo
backport/v15.0/forgejo
backport/v7.0/forgejo
backport/v8.0/forgejo
backport/v9.0/forgejo
breaking
bug
bug
confirmed
bug
duplicate
bug
needs-more-info
bug
new-report
bug
reported-upstream
code/actions
code/api
code/auth
code/auth/faidp
code/auth/farp
code/email
code/federation
code/git
code/migrations
code/packages
code/wiki
database
MySQL
database
PostgreSQL
database
SQLite
dependency-upgrade
dependency
Chi
dependency
Chroma
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Gitea
dependency
Golang
Discussion
duplicate
enhancement/feature
forgejo/accessibility
forgejo/branding
forgejo/ci
forgejo/commit-graph
forgejo/documentation
forgejo/furnace cleanup
forgejo/i18n
forgejo/interop
forgejo/moderation
forgejo/privacy
forgejo/release
forgejo/scaling
forgejo/security
forgejo/ui
Gain
High
Gain
Nice to have
Gain
Undefined
Gain
Very High
good first issue
i18n/backport-stable
impact
large
impact
medium
impact
small
impact
unknown
Incompatible license
issue
closed
issue
do-not-exist-yet
issue
open
manual test
Manually tested during feature freeze
OS
FreeBSD
OS
Linux
OS
macOS
OS
Windows
problem
QA
regression
release blocker
Release Cycle
Feature Freeze
release-blocker
v7.0
release-blocker
v7.0.1
release-blocker
v7.0.2
release-blocker
v7.0.3
release-blocker
v7.0.4
release-blocker
v8.0.0
release-blocker/v9.0.0
run-all-playwright-tests
run-end-to-end-tests
test
manual
test
needed
test
needs-help
test
not-needed
test
present
untested
User research - time-tracker
valuable code
worth a release-note
User research - Accessibility
User research - Blocked
User research - Community
User research - Config (instance)
User research - Errors
User research - Filters
User research - Future backlog
User research - Git workflow
User research - Labels
User research - Moderation
User research - Needs input
User research - Notifications/Dashboard
User research - Rendering
User research - Repo creation
User research - Repo units
User research - Security
User research - Settings (in-app)
Milestone
Clear milestone
No items
No milestone
Forgejo v12.0.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
forgejo/forgejo!7361
Reference in a new issue
No description provided.
Delete branch "mfenniak/forgejo:dynrefresh-actions-list"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?