The example was not a valid map, which caused issues with some openapi yaml converters.
I gave the two options proper values and also added them to the other team structs so the examples are identical.
Also sorted them as they are enumerated in the [unit model definition](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/models/unit/unit.go), which is why the diff is a bit ugly.
Fixes#9881
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11093
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Florian Pallas <mail@fpallas.com>
Co-committed-by: Florian Pallas <mail@fpallas.com>
Previously, when a project id was passed into the new issue form as a
query parameter, it wouldn’t be selected if the project belonged to the
user or organization instead of directly to the repository.
Resolvesforgejo/forgejo#8489
Signed-off-by: Nils Philippsen <nils@redhat.com>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/9906
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Robert Wolff <mahlzahn@posteo.de>
Co-authored-by: Nils Philippsen <nilsph@noreply.codeberg.org>
Co-committed-by: Nils Philippsen <nilsph@noreply.codeberg.org>
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>
Increase the default `SQLITE_TIMEOUT` from 500ms to 60s.
In #11179 this was bumped up to 5s. But when that was backported to v14 in #11220, it failed consistently in CI through a couple increases, until it was bumped up further to 60s. This PR updates the `forgejo` branch to the same so that in the future when Forgejo 15 is released, it isn't regressed. `test-sqlite` has been failing on `forgejo` occasionally as well, so this increase is justified on this branch for this reason as well.
Putting aside the tests, I think a high value for the timeout (this 60s) is generally safer for production usage than a small timeout. The worst case with a high timeout is a slow request when there is high write contention on the DB.
## 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.
- [ ] 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.
- **Will update** the documentation for the default value if approved.
- [ ] 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Other changes without a feature or bug label
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11292): <!--number 11292 --><!--line 0 --><!--description aW1wcm92ZSBTUUxpdGUgImRhdGFiYXNlIGlzIGxvY2tlZCIgZXJyb3JzIGJ5IGluY3JlYXNpbmcgZGVmYXVsdCBgU1FMSVRFX1RJTUVPVVRgICh0YWtlIDIp-->improve SQLite "database is locked" errors by increasing default `SQLITE_TIMEOUT` (take 2)<!--description-->
<!--end release-notes-assistant-->
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11292
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
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>
I noticed that the wrong content type in an `/upload` request can trigger a 500, and I'm guessing it is more appropriate to return 400 instead.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10954
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Roberto Vidal <roberto.vidal@ikumene.com>
Co-committed-by: Roberto Vidal <roberto.vidal@ikumene.com>
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>
This change fixes an issue that makes Forgejo clean up too many versions of a container package even though it should keep them according to the rules set for the package.
The issue affects multi-platform container images.
Forgejo adds a package version for each platform (for example `linux/amd64`, `linux/arm64`) in addition to the actual tag (for example `0.6.0` or `latest`).
This results in rows in the table `package_version` similar to this (unimportant columns omitted for brevity):
| **lower_version** | **created_unix** |
|---|---|
| `latest` | `1768742887`|
| `0.6.0` | `1768742886` |
| `sha256:038e...` | `1768742886` |
| `sha256:fc38...` | `1768742886` |
| `0.5.0` | `1768742864` |
| `sha256:806d...` | `1768742864` |
| `sha256:0a19...` | `1768742864` |
| `0.4.0` | `1768742848` |
| `...` | `...` |
The code assumes that the first `<keep count>` entries can be ignored and considers every entry after `<keep count>` as eligible for cleanup.
That doesn't work for multi-platform container images because, for `<keep count>=5`, it considers version `0.4.0` as eligible.
## 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...
- [x] 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.
- [ ] 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.
<!--start release-notes-assistant-->
## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Bug fixes
- [PR](https://codeberg.org/forgejo/forgejo/pulls/11246): <!--number 11246 --><!--line 0 --><!--description Y2xlYW51cCBvZiBtdWx0aS1wbGF0Zm9ybSBjb250YWluZXIgaW1hZ2Vz-->cleanup of multi-platform container images<!--description-->
<!--end release-notes-assistant-->
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11246
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: wandhydrant <wandhydrant@noreply.codeberg.org>
Co-committed-by: wandhydrant <wandhydrant@noreply.codeberg.org>
The general consensus I have gotten from past contributions is that `return nil, nil` is an
antipattern in Forgejo, especially because:
```go
val, err := Func()
if err != nil {
return
}
val.Func()
```
can easily lead to a nil pointer dereference.
This PR merely enables the lint and ignores all currently broken files. In addition to this PR,
a tracking issue to keep track of re-enabling nilnil linting on the ignored files could be
useful.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11235
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: famfo <famfo@famfo.xyz>
Co-committed-by: famfo <famfo@famfo.xyz>
Fixes: #11238
### Tests
- 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 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.
Co-authored-by: Diego Díez <diegodiez.ddr@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11240
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
Remove the documentation for the deprecated authentication methods Token and AccessToken. The functionality remains in place because it's still in use.
## 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.
- [ ] 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/11232
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Cyborus <cyborus@disroot.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
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>
### Tests
- 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 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.
### Disclaimer
Generative AI (ChatGPT) was used to debug the e2e test, with copied code lines below threshold of originality.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11156
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Reviewed-by: Andreas Ahlenstorf <aahlenst@noreply.codeberg.org>
Co-authored-by: Robert Wolff <mahlzahn@posteo.de>
Co-committed-by: Robert Wolff <mahlzahn@posteo.de>
`Option[T]` currently exposes a method `Value()` which is permitted to be called on an option that has a value, and an option that doesn't have a value. This API is awkward because the behaviour if the option doesn't have a value isn't clear to the caller, and, because almost all accesses end up being `.Has()?` then `OK, use .Value()`.
`Get() (bool, T)` is added as a better replacement, which both returns whether the option has a value, and the value if present. Most call-sites are rewritten to this form.
`ValueOrZeroValue()` is a direct replacement that has the same behaviour that `Value()` had, but describes the behaviour if the value is missing.
In addition to the current API being awkward, the core reason for this change is that `Value()` conflicts with the `Value()` function from the `driver.Valuer` interface. If this interface was implemented, it would allow `Option[T]` to be used to represent a nullable field in an xorm bean struct (requires: https://code.forgejo.org/xorm/xorm/pulls/66).
_Note:_ changes are extensive in this PR, but are almost all changes are easy, mechanical transitions from `.Has()` to `.Get()`. All of this work was performed by hand.
## 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.
- [ ] 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
- [ ] 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.
- [x] 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/11218
Reviewed-by: Otto <otto@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>
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>
As noted in https://codeberg.org/forgejo/forgejo/issues/10900#issuecomment-10339634, `TestAPICreateIssueParallel` is failing intermittently in Forgejo CI. Based upon this intermittent failure, I've made these changes:
- Increase the parallel run of the test from 10 instances to 100, which caused this test to fail consistently and reliably on my dev workstation. The test execution time at 100 parallel invocations is only ~4 seconds.
- Increase the default `SQLITE_TIMEOUT` from 500ms to 5s, which caused this test to succeed consistently on my dev workstation.
Is 5000ms the right setting? 🤷 On local testing, this specific test failed...
- 2500ms: failed 1/1 times
- 3000ms: failed 1/3 times
- 3500ms: failed 0/10 times
## 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.
- [ ] 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
- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. -- https://codeberg.org/forgejo/docs/pulls/1775
- [ ] 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/11179
Reviewed-by: Michael Kriese <michael.kriese@gmx.de>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
Forgejo's UI claims that whitespace is removed from the beginning and the end of the values of Forgejo Actions variables and secrets. However, that is not correct. The entered values are stored as-is. Only CRLF is replaced with LF, which is also the desired behaviour.
This PR changes the incorrect text which is also no longer displayed as placeholder but as a proper help text below the input fields. Furthermore, tests were added to verify the behaviour.
While adding tests, I discovered and fixed another inconsistency. Depending on whether secrets were managed using the UI or the HTTP API, they were treated differently. CRLF in secrets entered in the UI was correctly replaced with LF while secrets created using the HTTP API kept CRLF.
Fixes#11003.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11052
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
Co-committed-by: Andreas Ahlenstorf <andreas@ahlenstorf.ch>
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>
Display version without compat metadata for admins too, not just for regular users. It was confusing to some, though I don't remember who got confused.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11196
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>
Slightly related to https://codeberg.org/forgejo/forgejo/pulls/11196, but it has no tests related to the change in that PR.
Added tests because I wanted those config options be tested, but haven't found any existing tests.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11197
Reviewed-by: Beowulf <beowulf@beocode.eu>
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
Co-committed-by: 0ko <0ko@noreply.codeberg.org>
Fixes#11083.
## 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...
- [x] 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.
- [ ] 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.
Co-authored-by: f <f@sutty.nl>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/11153
Reviewed-by: Mathieu Fenniak <mfenniak@noreply.codeberg.org>
Co-authored-by: fauno <fauno@noreply.codeberg.org>
Co-committed-by: fauno <fauno@noreply.codeberg.org>
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>
Stores the entire list of AssigneeIDs for each issue in the indexer.
This fixes the bug where there were missing entries for issues with assignees while filtering.
Note: Will re-index all issues
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/10552
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Co-committed-by: Shiny Nematoda <snematoda.751k2@aleeas.com>
Adds a CI check which detects any usage of xorm's `Sync` method that doesn't include `IgnoreDropIndices: true`, and causes an error.
`semgrep` is a semantic grep tool that allows for the relatively easy authoring of linting tools that are customized to a project's specific needs, rather than generic like `golangci` and related tools. Although `semgrep` offers a suite of out-of-the-box rules (and a paid set of rules), neither of those are used here -- only one Forgejo-specific rule is added in `.semgrep/xorm.yaml`.
My intent with this change is to introduce the idea and infrastructure of `semgrep` with a single minimal rule. Once in-place, this will become a tool that we can use when we recognize bad coding patterns and wish to correct them permanently, rather than relying on human code review. While generic linting tools do this well for general patterns, this will allow Forgejo to apply domain-specific checks. For example, in #11112, an error indicates that it might be appropriate for us to always use `.StorageEngine("InnoDB")` when using an xorm engine -- if we made that determination, it could be cemented in-place with a `semgrep` rule relatively easily.
This specific rule looks for any access for xorm's `Sync` or `SyncWithOptions` methods on the `*xorm.Engine` or `*xorm.Session`. They are then considered errors if they don't include `IgnoreDropIndices: true`. This is *typically* correct and safe, but can also be ignored when specifically needed. In the `.semgrep/tests` folder, test code is added which validates that the `semgrep` rule matches the expected patterns; this self-test is run before `semgrep` runs on the PR in CI.
As a demonstration, when `IgnoreDropIndices` is removed from a migration, here's an error: https://codeberg.org/forgejo/forgejo/actions/runs/135750/jobs/12/attempt/1
```
models/forgejo_migrations/v14b_add-action_run-preexecutionerrorcode.go
❯❯❱ semgrep.xorm-sync-missing-ignore-drop-indices
xorm Sync operation may drop indices if used on an incomplete bean definition for an existing table.
Use SyncWithOptions with IgnoreDropIndices: true instead.
22┆ _, err := x.SyncWithOptions(xorm.SyncOptions{}, new(ActionRun))
```
## 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.
- [ ] 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
- [ ] 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.
- [x] 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/11142
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Mathieu Fenniak <mathieu@fenniak.net>
Co-committed-by: Mathieu Fenniak <mathieu@fenniak.net>
