Fixes https://codeberg.org/forgejo/forgejo/issues/12082 by reverting commit dd968f147d.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for Go changes
(can be removed for JavaScript changes)
- 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 ran...
- [ ] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] 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.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [ ] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12088
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
This is hopefully the final part of PR #4767, rebased and squashed.
More thorough federation tests are at https://code.forgejo.org/forgejo/end-to-end/pulls/1276 but the mock has been extended to hopefully cover a good chunk as well.
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-authored-by: zam <mirco.zachmann@meissa.de>
Co-authored-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10380
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
Fixes#6438
When a protected branch requires signed commits and no signing key is available, fast-forward-only merges should still be allowed because they do not create a new commit.
This patch applies signing checks by merge behaviour/style instead of one global gate:
- pass `mergeStyle` through `CheckPullMergeable(...)` in web/API/automerge paths
- require signing for commit-creating styles (`merge`, `rebase`, `rebase-merge`, `squash`)
- bypass signing precheck only for `fast-forward-only`
- align merge UI options with backend behaviour so signing-dependent styles are unavailable when signing cannot happen
- add Go unit tests for merge-style signing requirements
- add frontend unit coverage for the no-allowed-merge-styles guard
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11403
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: abdo <dev@abdo.wtf>
Co-committed-by: abdo <dev@abdo.wtf>
Since https://codeberg.org/forgejo/forgejo/pulls/11750, the attempt number of a Forgejo Actions job is set eagerly. When an job is ultimately not run, for example, because its `needs` weren't satisfied, it leads to discontinuous attempt numbers of completed attempts that the component for viewing action logs could not handle. This has been rectified by actually determining the number of the last attempt.
Resolves https://codeberg.org/forgejo/forgejo/issues/11994.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/12021
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
https://codeberg.org/forgejo/forgejo/issues/11116
To understand the impact of this you really need to listen to the before and after screen recordings attached. https://codeberg.org/forgejo/forgejo/issues/11116 is a really great bug report, and I was surprised by how disorienting this actually was when testing manually compared to my expectation after reading the issue. This is an impactful improvement!
This is my first time adding new translation strings. Excited to learn more about that if I've guessed wrong about how to do it.
To summarise, what we're doing here is as follows.
1. Address the core issue by changing the existing `<th>` elements to `<td>` so that screen readers stop semantically associating them with each row and reading them out for every table cell.
2. Replace them with real `<th>` elements that communicate the true semantic role of each column.
3. Add a `<caption>`. This serves a dual purpose: it gives the table an accessible name which improves the navigability of the page, and it gives us a place to explain to the user that the first row of the table is a little bit different because it's the latest commit rather than a file in the repo.
4. Visually hide the new caption and headings so that only screen reader users get them.
## Checklist
The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. All work and communication must conform to Forgejo's [AI Agreement](https://codeberg.org/forgejo/governance/src/branch/main/AIAgreement.md). 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 for JavaScript changes
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] 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.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11846
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes#11842.
The `once: true` was likely added to prevent multiple concurrent
submissions of the same form. This could still be worth preventing,
but I suspect it would require wrapping the supplied `onApprove`
callback with the corresponding logic, implemented manually, as I
am not aware of any native API to prevent concurrent executions of
callbacks.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11843
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Fixes https://codeberg.org/forgejo/forgejo/issues/7668.
This was simpler to fix than my theory I posted on https://codeberg.org/forgejo/forgejo/issues/7668 about needing to patch the upstream package. When testing in Firefox with the developer console open and warnings enabled, I noticed a `Empty string passed to getElementById()` warning coming from `@github/combobox-nav` while attempting to manage the `aria-activedescendant` attribute. Then I found this in the [README for that project](https://github.com/github/combobox-nav).
> Markup requirements:
> - Each option needs to have role="option" and a unique id
This was easy to miss, as we're using `@github/text-expander-element` and the combobox-nav package is one of _its_ dependencies. Without a unique ID on each dropdown menu item, `@github/text-expander-element` is unable to set an appropriate `aria-activedescendant` attribute on the textarea. Once that's in place, the screen reader announcements come to life beautifully.
While working on it I noticed the emoji picker combobox was affected by the same problem and patched that as well.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11860
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes https://codeberg.org/forgejo/forgejo/issues/9894.
The dropdown menu items are being hidden with `.tw-hidden`. The Fomentic dropdown makes items with `.disabled` and `.filtered` unselectable by default but can be [easily configured](https://fomantic-ui.com/modules/dropdown.html#/settings) to broaden this selector.
In the before & after GIFs attached, there is an archived label between "duplicate" and "help wanted". In the before GIF, focus disappears momentarily between the two, which is when the hidden, archived label has been programmatically focused by Fomentic. In the after GIF, focus hops instantaneously between the two selectable labels because of the broader `unselectable` selector.
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] 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.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11858
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
Fixes#1529.
This adds an "Add member" button to the list of members of an organization, offering a more intuitive way to add a user to an organization (instead of going through the list of teams).
This follows the design proposed in #1529. This PR can already be reviewed as such, but I plan to work on follow-up improvements:
- adding a confirmation dialog when adding the new member to the "Owners" team, since they get absolute rights on the org
- adding a text input to filter the list of teams, making it easier to select the desired teams when there are many of them
- potentially, improving the team creation link so that it brings the user back to the modal dialog once the team is created (but I'm not sure there's a ton of value behind this added complexity, since currently, creating a team will lead the user to the team page, which is a good place to add the member to the team)
This new way of adding members does not support issuing email invites, since we decided in #9884 that the invite feature hasn't got good enough of a UX to advertise it yet. Following [this discussion](https://codeberg.org/forgejo/discussions/issues/441), I am planning to work on enabling invites everywhere (potentially even making it the default).
## Checklist
### Tests for Go changes
- I added test coverage for Go changes...
- [ ] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
- 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 plan to update https://docs.codeberg.org/collaborating/create-organization/#people once we are ready to take final screenshots of the feature.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
### Screenshots
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11848): <!--number 11848 --><!--line 0 --><!--description IkFkZCBtZW1iZXIiIGJ1dHRvbiBpbiBvcmcgbWVtYmVycyBsaXN0-->"Add member" button in org members list<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11848
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Previously, a scheduled run would appear like a run triggered by a push. That could be confusing, especially if a scheduled run was unrelated to that particular commit. Now, either the workflow's name (taken from the field `name:`) is displayed or the path to workflow file, matching the behaviour of `workflow_dispatch`.
As a side-effect, the description of all run types were improved. They are no longer pieced together from individual translations. `workflow_dispatch` also no longer misattributes commits to the user that triggered the workflow.
Resolves https://codeberg.org/forgejo/forgejo/issues/11688.
## 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 for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- I added test coverage for JavaScript changes...
- [ ] in `web_src/js/*.test.js` if it can be unit tested.
- [ ] 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11770
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Adds a user interface for creating repo-specific access tokens (#11311). When the new option "Specific repositories" is selected, a search option appears. Each repository in the search result has an "Add" button to include it on the access token, and once included, a repository can be removed with the "Remove" button. This is a JS-free form.
## 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 for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [ ] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
- 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)).
- Technically there are no "JavaScript changes" in this PR, but e2e tests were added for browser interaction testing.
### Documentation
- [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change.
- TODO: planning to create documentation in https://forgejo.org/docs/next/user/token-scope/; there is none for public only tokens but I think this seems like a good place to add both.
- [ ] I did not document these changes and I do not expect someone else to do it.
### Release notes
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11696
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
https://codeberg.org/forgejo/forgejo/issues/11512
Restoring default whitespace behaviour seems sufficient to resolve this. The `display: block` property is necessary because `<small>` is an inline element and otherwise the `padding-left` only applies to the first line. There's a description in one of the default label packages affected by the issue so I've used that for the before/after screenshots below.
| Before | After |
|-|-|
|  |  |
The issue doesn't just affect long descriptions though. In fact even the nice, short defaults are affected. Vision impairment is one of the most common disabilities, and increasing the text size is a typical way in which people adapt their computing environment to accommodate their disability. Even the short default label descriptions are cut off in this use case.
| Before | After |
|-|-|
|  |  |
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11607
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Henry Catalini Smith <henry@catalinismith.se>
Co-committed-by: Henry Catalini Smith <henry@catalinismith.se>
We are updating the user's personal access token page (`/user/settings/applications`) to allow the creation of repo-specific tokens, adding a third option to "Repository and Organization Access". In preparation for this new UI, this PR moves the creation of access tokens to a new page accessed by "New access token".
This also resolves a pet-peeve: the "Select permissions" dropdown on the inline edit form hides a *required* input for an access token. This section is expanded on the new dedicated page. (The Vue component used here is replaced with a JS-free alternative as well. This form component used to lose selected values when an error occurred, and it didn't make sense as a Vue component, so it has been translated into an HTML template instead.)
## 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 for Go changes
- 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 ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
- 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11659
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Closes#11400
Overflow is handled by javascript to show a button instead of horizontally scrolling, this is not the case when javascript is disabled. Add CSS to handle overflow, does not interfere with the javascript.
## Testing
1. Go to any repository.
2. Turn off javascript.
3. Make viewport width small.
4. Observe that repository menu under the repository header doesn't overflow.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11614
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Artyom Bologov <git@aartaka.me>
Co-committed-by: Artyom Bologov <git@aartaka.me>
Followup to https://codeberg.org/forgejo/forgejo/pulls/11516 which I didn't have time to review. Some consistency fixes.
Haven't done anything with the [actions in the table](https://codeberg.org/attachments/5a7eb4f2-c45c-4189-b952-ca4cd4085eb5) but something will need to be done. Like an ellipsis menu.
## Preview
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11675
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Forgejo Runner is deprecating the runner registration token. It is too powerful, requires tooling, and is unnecessary. As a consequence, users need new mechanisms for managing runners in Forgejo. https://codeberg.org/forgejo/forgejo/pulls/10677 added an HTTP API for runner registration. This PR adds the ability to manage runners using Forgejo's web interface.
Runners can be added, modified, and deleted. It is also possible to regenerate a runner's token. When a runner is added or a runner's token is regenerated, setup instructions are displayed. They explain how to alter Forgejo Runner's configuration file or how to launch `forgejo-runner daemon` (yet to be implemented). The existing details page has been overhauled and is now accessible to all users that are allowed to use a particular runner. The details page displays additional information that had to be removed from the list of runners due to space constraints. The task list is filtered. That means it only lists jobs of the respective repository, user, or organization.
The runner registration token has been marked as deprecated.
See https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/88 for context and design considerations.
## 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 for Go changes
(can be removed for JavaScript changes)
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server.
- I ran...
- [x] `make pr-go` before pushing
### Tests for JavaScript changes
(can be removed for Go changes)
- 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
*The decision if the pull request will be shown in the release notes is up to the mergers / release team.*
The content of the `release-notes/<pull request number>.md` file will serve as the basis for the release notes. If the file does not exist, the title of the pull request will be used instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11516
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
- For small modals fomantic tried to add a `scrolling` class using a function that was not implemented, this function is now stubbed.
- There's not really a need to conditionally change the behavior of scrolling or not, we can specify `overflow-y: auto` which is more than enough to take care of this. We do add some layout changes to ensure the modal is fully scrollable.
- Refactor to nested CSS.
- Resolvesforgejo/forgejo#10991
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11547
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
Closesforgejo/forgejo#11407
I looked at related Gitea discussions for when it was implemented and it looks like what to use exactly for `overflow` was not discussed, the intention was just to have overflowing content scroll, not to have irrelevant scrollbars appear at all times.
- https://github.com/go-gitea/gitea/pull/31683
- https://github.com/go-gitea/gitea/issues/31667
- https://github.com/go-gitea/gitea/pull/26561
But with `max-height` restrictions that are in place only horizontal scrollbars are ever needed on demand. Vertical ones are not needed. For this `auto` works much better than `scroll`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11469
Reviewed-by: Beowulf <beowulf@beocode.eu>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Fixes#11268
Fixes regression of #9614
Calling `initDisabledInputs` wasn't effective for template contents, so inputs in MDEs spawned by repo-legacy.js on comment editing were broken. Now repo-legacy.js also calls it when it spawns a new MDE.
Co-authored-by: Gusted <Gusted@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11341
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Fixes#11036.
This adds a link from a CI run to the file that its workflow was taken from.
| Before | After |
|---------|---------|
|  |  |
Before:
* the `test.yml` link points to the list of other runs (`/org123/repo2/actions?workflow=test.yml`)
After:
* the `test.yml` link points to the workflow definition (`/org123/repo2/src/commit/55b048363c8cfa7d9e8b5cade5c75681bd0c7328/.forgejo/workflows/test.yml`)
* the `all runs` link points to the list of other runs (`/org123/repo2/actions?workflow=test.yml`)
I have tried to retain the existing link to the list of workflow runs (moving it to a separate link), but I am not sure if this link should be retained at all and if so how.
## Checklist
### Tests
- I added test coverage for Go changes...
- [x] in their respective `*_test.go` for unit tests.
- [x] 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
- [x] This change will be noticed by a Forgejo user or admin (feature, bug fix, performance, etc.). I suggest to include a release note for this change.
- [ ] This change is not visible to a Forgejo user or admin (refactor, dependency upgrade, etc.). I think there is no need to add a release note for this change.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11216): <!--number 11216 --><!--line 0 --><!--description bGluayBDSSBqb2IgdG8gaXRzIGRlZmluaW5nIHdvcmtmbG93IGZpbGU=-->link CI job to its defining workflow file<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11216
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Antonin Delpeuch <antonin@delpeuch.eu>
Co-committed-by: Antonin Delpeuch <antonin@delpeuch.eu>
Add `flex` or `inline-flex` to the direct parent element of the SVG icon in the navigation bar to make the overall alignment look better.
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11259
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: panc <pan0xc@foxmail.com>
Co-committed-by: panc <pan0xc@foxmail.com>
Replaces https://codeberg.org/forgejo/forgejo/pulls/11271
This rule was problematic and didn't quite make sense:
* the intention is to have a navbar that is 48px+1px border
* we apply `min-height:49px` to: `#navbar` with intention of making it 49px tall total, with border
* but we also apply it to `#navbar .navbar-left/right`
* elements `#navbar .navbar-left/right` become 49px tall
* their parent `#navbar` becomes 49px+1px border = 50px, overriding what was done in step 2
This height missmatch had an incompatibility with this definition for open menu inside of navbar on mobile, causing jitter when the menu is opened/closed, because it was expecting navbar body to be 48px, but due to the rule that was removed it was actually 49px.
```css
#navbar.navbar-menu-open .navbar-left .navbar-mobile-right {
min-height: 48px;
}
```
The fix is to only apply `min-height` to `#navbar`'s children. At least `.navbar-left` is always expected to be present unconditionally on all pages. This does make the navbar 1px shorter. If we still want a 50px navbar but without the bug let me know and I'll adjust.
### Preview by @panc
From https://codeberg.org/forgejo/forgejo/pulls/11271, also applies to this PR.
| Before | After |
|----|----|
| <video src="/attachments/515fdfc1-cb97-46af-88ac-9bb0e216a996" title="Screencast From 2026-02-13 19-56-32" controls></video> | <video src="/attachments/133d1499-4660-402d-8082-f407b3644e5c" title="Screencast From 2026-02-13 19-57-29" controls></video> |
Reported-by: panc <panc@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11274
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
The navigation menu on mobile is divided into two sections, but there is no gap between them. I referred to the following code and set the gap to `gap: .35714286em`
```CSS
.ui.secondary.menu {
margin-left: 0;
margin-right: 0;
gap: .35714286em;
}
```
| Before | After |
|--------|-------|
|  |  |
| Before | After |
|--------|-------|
|  |  |
Another thing to note is that the dot of the stopwatch extends beyond the background.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11262
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: panc <pan0xc@foxmail.com>
Co-committed-by: panc <pan0xc@foxmail.com>
Defines new css colours for theming:
```css
--color-selection-bg: var(--color-primary-light-1);
--color-selection-fg: var(--color-white);
```
which are then used both in the `base.css` and in the relative-time shadow object.
This, is how it looks for me when selecting before and after this patch (my Browser’s accent colour used for selection is orange):
| | Before | After |
|---|---|---|
| Forgejo Light |  |  |
| Forgejo Dark | |  |
| Gitea Light |  |  |
| Gitea Dark |  |  |
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11231
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
Replaces #10789
Convert the layout from flex-list helpers to a CSS-native grid. This allows to having buttons in different rows aligned to each other while keeping the layout responsive, i.e. looking good on both desktop and mobile.
### Preview (desktop)
|Before|After|
|-|-|
|||
### Preview (mobile)
|Before|After|
|-|-|
|||
### Preview (Guest)
|Before|After|
|-|-|
|||
## Testing
Automated tests were added to make sure that actions in this list are still working, and for basic template logic. No tests were added for layout because layout being correct is an abstract concept that is difficult to explain to Playwright.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11127
Reviewed-by: Antonin Delpeuch <wetneb@noreply.codeberg.org>
Normalizes the issue/pr title case when searching if it contains any of the wip prefixes, which are also normalized, just in case.
Fixes#11189
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11190
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
Adds a new button on the right side of the label's filter menu items to explicitly exclude labels.
The new button is reachable with the keyboard by using the vertical arrow keys to reach the label you want to exclude and then the horizontal arrow keys to select the exclusion button.
The new button will only be visible when hovering the menu item or reaching it with the keyboard.
Adjusted the alignment of labels when at least one label is selected so that users can clearly discern which labels are selected or not.
Resolves#3302
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10702
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Luis <luis@adame.dev>
Co-committed-by: Luis <luis@adame.dev>
## Changes
I've made releases list more usable on narrow viewports while trying keep the layout unchanged for desktop viewports.
To support these changes large amount of Tailwind classes were converted to regular CSS to be applied conditionally via `@media`. While it was possible to just adjust the Tailwind classes to achieve the same behavior, there's a positive effect which is that the repeating HTML of releases generated by template's range is much less verbose and contains fewer long duplicated lines of Tailwind classes.
## Preview
### Desktop
Not much changed, but the dot between tag and release name is no more.
|Before|After|
|-|-|
|||
### Mobile
|Before|After|
|-|-|
|||
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11080
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Beowulf <beowulf@beocode.eu>
Followup to https://codeberg.org/forgejo/forgejo/pulls/6154
en-US:
two days ago -> 2 days ago
two weeks ago -> 2 weeks ago
two months ago -> 2 months ago
two years ago -> 2 years ago
Other locales still require changes to ensure
that the relative time numbering is consistent.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10691
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: lily <lesson085@gmail.com>
Co-committed-by: lily <lesson085@gmail.com>
It has always been largely used for showcasing UI elements but that name didn't work too well for it.
Testing:
Some of existing tests depend on these pages, making it redundant to create extra tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11019
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
The custom styles for tippy-enabled menus had too broad selectors, conflicting with styles of other .item elements in tippy boxes.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10969
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Followup to https://codeberg.org/forgejo/forgejo/pulls/7746
Replaces https://codeberg.org/forgejo/forgejo/pulls/10938
grid layout (desktop): give the Compare button a wrapper with same height as the first text line so it stays aligned to it (and to timeline badge)
inline layout (mobile): give the Compare button left margin so there's a gap between it and the text line
Initial fix for grid was proposed by luisadame.
Co-authored-by: Luis <luis@adame.dev>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10939
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
This variable isn't needed because all themes are setting it to `--color-text`, but the relevant UI elements are already inheriting it from `body`.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10898
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
