Fix these `go vet` errors which I stumbled upon because AI likes to run
`go vet` standalone and `go vet` does not understand `//nolint` like
golangci does, so it produced confusing output.
Co-authored-by: bircni <bircni@icloud.com>
The bleve path token filter added in
https://github.com/go-gitea/gitea/pull/32210 never generated the full
path of a file, so searching a file by its path (e.g. `potato/ham`)
found nothing. It also gave the path tokens made-up offsets instead of
their position in the path.
The filter is replaced by a tokenizer that emits the raw path suffixes
starting at each segment and word (`potato/ham.md`, `ham.md`). Paths
below the root now match too, as do names containing `-` or spaces and
dotfiles. An exact file name also ranks above files inside a directory
with the same name.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fixes https://github.com/go-gitea/gitea/issues/39395
`findActionKeywords` ran the close and reopen keyword patterns over all
content before each reference, making `FindAllIssueReferences` quadratic
on comments and commit messages. The patterns are anchored at the
reference, so only the last few bytes can match. Scan only that window,
sized from the longest keyword with room for `(?i)` matching wider runes
like `ſ` for `s`.
`"#1 "` repeated 4000 times: 2.04 s before, 16 ms after.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fixes#39189.
`IsUserBlockedBy` intentionally treats admin users as not blocked, but
`CanUnblockUser` was also using it to determine whether a blocking
relationship exists. If a previously blocked user is later promoted to
admin, the existing `user_blocking` record remains but can no longer be
removed.
This change separates those two concerns by adding `HasBlocking` for
checking the persisted blocking relationship. `CanUnblockUser` uses that
relationship check while `IsUserBlockedBy` keeps its existing admin-user
behavior.
A regression test verifies that an admin is still not considered blocked
while an existing blocking relationship can still be unblocked.
Since #39229 the commit page header dereferences
`.Verification.CommittingUser` when the committer is not the author.
`Verification` is `nil` for unsigned commits (see `repo.Diff`), so
opening such a commit — a rebased or cherry-picked one, for example —
logs a template error and the page comes out truncated:
```
Render failed: failed to render template: repo/commit_page, error: template error: builtin(bindata):repo/commit_page:138:22 : executing "repo/commit_page" at <.Verification.CommittingUser>: nil pointer evaluating interface {}.CommittingUser
```
This guards the access and adds an integration test that creates a
commit with distinct author and committer identities and checks the page
renders completely (the status stays 200 on a mid-render failure, so the
test looks at the body).
_The fix was worked out with help from an AI assistant; I reviewed and
tested it myself._
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
`git commit --message=` passes the merge message as a single argument,
which Linux caps at 128 KiB and Windows at 32 KiB for the whole command
line. Long messages failed with `argument list too long` and the merge
box toast showed the raw HTML 500 page.
Pass the message via `--file=-` on stdin instead, and answer
fetch-action requests with JSON on server errors so the toast shows the
error text. Limits merge commit messages to 512KB which could be
extended or made configurable later.
Fixes: https://github.com/go-gitea/gitea/issues/39261
Fixes: https://github.com/go-gitea/gitea/issues/30276
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Update all eslint plugins and configure the new unicorn rules.
The new unicorn CSS rules stay off because stylelint already covers most
of them.
`unicorn/prefer-iterator-helpers` is disabled because it forces too-new
browser requirements onto Gitea.
No new violations in the code.
`app.example.ini` documented cron success notices with keys Gitea does
not read:
1. `[cron.update_checker]` had `ENABLE_SUCCESS_NOTICE`, which never
existed.
2. Six sections still had `NO_SUCCESS_NOTICE`, removed in
https://github.com/go-gitea/gitea/pull/19221. Its `false` value also
implied notices were on, while the default is off.
Cron sections map onto `BaseConfig`, whose `NoticeOnSuccess` binds to
`NOTICE_ON_SUCCESS`. This documents that key for every cron task, adds
it to four sections that omitted it, and fixes the "Notice if not
success" descriptions that inverted its meaning.
Signed-off-by: Roshan Ramani <roshanramani.dev@gmail.com>
Co-authored-by: silverwind <me@silverwind.io>
Fixes https://github.com/go-gitea/gitea/issues/39347
1. Focus the confirm button in generic confirm modals so `Enter` runs
the highlighted action.
2. Delete actions that lacked the risky flag now get it, so their
confirm button is red.
---------
Co-authored-by: silverwind <me@silverwind.io>
Follow-up to https://github.com/go-gitea/gitea/pull/38966. Replaces the
unreleased `POST /admin/users/{username}/convert-type` endpoint with a
`type` field on `PATCH /admin/users/{username}`.
Adds first-class bot accounts (`UserTypeBot`): local, password-less
users for automation that authenticate only with access tokens.
1. Admin UI: create bots, filter users by type, manage a bot's access
tokens, convert between user and bot
2. API: `POST /admin/users/{username}/convert-type`, and user objects
gain a GitHub-compatible `type` (`User`, `Organization`, `Bot`)
3. CLI: `gitea admin user change-type`, `--user-type` accepts `User` or
`Bot` case-insensitively
4. Converting keeps the password, 2FA, OAuth2 grants and access tokens,
and since sign-in rejects bots, converting back restores the account.
Only local, non-admin accounts can be converted, and conversions are
audited
5. Session, reverse proxy, SSPI, external source and password reset
sign-in reject non-individual users, so a bot never gets an interactive
session
6. Bots receive no notifications or emails
Co-authored-by: Nicolas <bircni@icloud.com>
Co-authored-by: joestump <joe@joestump.net>
Co-authored-by: Joe Stump <joe@stu.mp>
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Update to [mermaid
v12](https://github.com/mermaid-js/mermaid/releases#release-mermaid@12.0.0),
ELK is now the default layout so the plugin and all supporting code is
gone.
Layout switching to previous `dagre` layout via frontmatter works as
expected. Diagrams use the new `neo` default look which renders them
slightly different (smaller boxes) then the `classic` look that was
default in v11.
The `neo` look got some tweaks to remove shadows and gradient to look
better. Also did some related refactors and mermaid dragging now works
on touch devices too.
Fixes the `app.example.ini` half of #39224.
The comment says:
> If a domain is allowed by `ALLOWED_DOMAINS`, this option will be
ignored.
That is no longer true. `checkByAllowBlockList` in
`services/migrations/migrate.go` consults the block list **first** and
returns immediately:
```go
if blockList.MatchHostName(hostName) || ipBlocked {
return &git.ErrInvalidCloneAddr{Host: hostName, IsPermissionDenied: true}
}
// if we have an allow-list, check the allow-list before return to get the more accurate error
if !allowList.IsEmpty() { ... }
```
`IsMigrateURLAllowed` resolves the host with `net.LookupIP` and passes
the addresses in, so with `ALLOW_LOCALNETWORKS = false` a host that
appears in `ALLOWED_DOMAINS` is still rejected once any resolved address
is private or loopback — the allow list never gets a look. The reporter
traced this to the validation hardening in #38324 / #38400, and the code
matches their description.
The new wording states the precedence rather than the old override
claim.
Scope: this only covers `custom/conf/app.example.ini`, which lives here.
The same stale sentence is on the config cheat sheet in `gitea/docs`
(both the English and zh-cn pages) per the issue; that is a separate
repository.
Assisted-by: Claude, via Claude Code
Sync Fork already maps merge conflicts to a JSON error. Unrelated
histories still went through `ServerError`, so the UI showed a 500 HTML
snippet instead of the same user-facing message PR merge already uses
(`repo.pulls.unrelated_histories`).
The API path returned 500 for the same git error; PR merge returns 409.
Match that.
Fixes#36772
AI assistance was used to locate the handler gap and draft the mapping.
I reviewed and take responsibility for the change.
Signed-off-by: Zhaoqi Xu <lzy00419@outlook.com>
`modulePreload: false` came in with the webpack to vite migration, when
chunks were cache-busted through import maps. With content-hashed chunks
that reason is gone. Vite's default makes every lazy import preload its
whole static dependency tree in parallel instead of the browser
discovering it one level per round trip, which renders lazy features like
mermaid, the code editor and the activity charts noticeably faster on
real-world latency without changing chunks or requests.
Assisted-by: Claude Code:claude-opus-5
