Gitea

Recent Commits

• silverwind(24 Oct 26)

  docs: update AGENTS.md and dev docs (#39976) Agents rarely read the `docs` guides when AGENTS.md only asks for relevant ones. AGENTS.md now names the guide for each area, and rules agents kept missing go into those guides. - AGENTS.md maps Go, TS, CSS, Vue, templates, tests, config options, migrations and refactors to their guide - The backend guide lists XORM pitfalls behind recent bugs (https://gitea.com/xorm/xorm/issues/2615): zero-valued struct conditions, `Cols` and `updated` columns on updates, soft-delete values, index drops by `SyncAllTables`, MSSQL limits and pagination order - The development guide requires a `WIP:` companion docs PR copying the ini text verbatim for `app.example.ini` changes, and says to avoid migrations unless the alternative is a workaround

• silverwind(24 Oct 26)

  test: consolidate Go tests (#39962) Consolidate all Go tests. Coverage is identical to before. Go tests are around 5% faster while being 7% smaller. No non-test code is touched.

• fixfon(24 Oct 26)

  fix: get valid UTF-8 for diff_hunk and composer readme (#39932) * Fixes #39929 * Fixes #39994 Co-authored-by: silverwind <[email protected]> Co-authored-by: wxiaoguang <[email protected]>

• Basavaraj S m(24 Oct 26)

  fix(actions): drop untrusted Content-Encoding from v1 artifact uploads (#39855) Legacy (v1 to v3) artifact uploads stored the request's `Content-Encoding` header in the column that v4 artifacts read as their `Content-Type`. - Store only the `gzip` marker on legacy uploads, the only encoding their clients send - Pick the PDF and audio/video serve headers only for content types that `mime.ParseMediaType` accepts --------- Co-authored-by: silverwind <[email protected]>

• schop-rob(24 Oct 26)

  fix(diff): load both blobs of renamed files for diff rendering (#39969) When opening a pull request that renamed a CSV file: the compare page fails with a 500. Fix: load the left blob for every file that was not added, and the right blob (from `Name`) for every file that was not deleted. That matches what the templates did before #38517. Co-authored-by: Claude Opus 5.5 <[email protected]> Co-authored-by: wxiaoguang <[email protected]>

• wxiaoguang(24 Oct 26)

  refactor: username sub route (#39967) Remove the workaround for chi router, do as much as possible in middlewares --------- Co-authored-by: silverwind <[email protected]> Co-authored-by: Giteabot <[email protected]>

• silverwind(24 Oct 26)

  feat: Improve Gitea-compatible forge migrations, fix many migration bugs (#39424) Supports migrating from Gitea-compatible forges like Forgejo and fixes many migration bugs. 1. Pre-release and `+gitea-` suffixed server versions no longer drop reviews, reactions and pagination. 2. Review states, dismissals, scoped and archived labels and merge bases are migrated. 3. Disabled units, external trackers, unavailable release assets, and GitLab confidential issues and internal notes are skipped. 4. Credentials are only sent to the source host, and `Retry-After` rate limits are waited out. 5. GitHub migrations of only issues or pull requests, basic auth clones and dismissed reviews work again. 6. The API returns 404 for releases of a disabled unit and shows migrated authors as mannequins, replacing the never populated `original_author` and `original_author_id` fields. Fixes: https://github.com/go-gitea/gitea/issues/19533 Fixes: https://github.com/go-gitea/gitea/issues/35885 Fixes: https://github.com/go-gitea/gitea/issues/18275 Fixes: https://github.com/go-gitea/gitea/issues/35069 Fixes: https://github.com/go-gitea/gitea/issues/17763 Fixes: https://github.com/go-gitea/gitea/issues/39548 Co-authored-by: bircni <[email protected]>

• GiteaBot(24 Oct 26)

  [skip ci] Updated translations via Crowdin

• Mitrahsoft(24 Oct 26)

  feat(api): add REST API endpoints for repository webhook delivery history (#38775) Webhook delivery history (request/response, status, timestamp) was only reachable through the repo settings UI, which shows the last ~10 deliveries with no filtering. There was no way to fetch this data programmatically for debugging integrations or auditing webhook activity. This adds two read endpoints at the repository level: - `GET /repos/{owner}/{repo}/hooks/{id}/deliveries` — paginated list of a hook's deliveries, most recent first - `GET /repos/{owner}/{repo}/hooks/{id}/deliveries/{uuid}` — a single delivery, including request/response headers, body, and status Both reuse the existing `hook_task` storage and retention policy (the `CleanupHookTaskTable` cron job) that already back the "Recent Deliveries" web UI, and are gated by the same `reqAdmin()` + `reqWebhooksEnabled()` guard as the existing hook endpoints. Org, user, and admin/system-level webhooks are intentionally out of scope for this PR to keep it reviewable; they can follow as separate PRs using the same pattern. ## Usage ```bash curl -H "Authorization: token $TOKEN" \ https://gitea.example.com/api/v1/repos/{owner}/{repo}/hooks/{id}/deliveries curl -H "Authorization: token $TOKEN" \ https://gitea.example.com/api/v1/repos/{owner}/{repo}/hooks/{id}/deliveries/{uuid} ``` ## Testing - Unit tests for the new model-layer query functions (`ListHookTasks`, `GetHookTaskByUUID`) - Integration tests covering: list + get, an undelivered task's response is `null`, a hook/delivery UUID from another repository 404s instead of leaking across repos, and pagination (`page`/`limit`, `Link` and `X-Total-Count` headers, correct ordering/no overlap across pages) - `make lint-go`, `make generate-swagger` Fixes: https://github.com/go-gitea/gitea/issues/38463. Co-authored-by: bircni <[email protected]> Co-authored-by: silverwind <[email protected]>

• Shivansh Garg(23 Oct 26)

  enhance(project): filter project milestones by linked issues (#39958) The project milestone filter listed every milestone of the repo, or of all accessible org repos for org projects, including ones with no issue in the project. That made the dropdown noisy and unhelpful. Both repo and org projects now list only milestones that have at least one issue linked to the project, via a new `ProjectID` option on `FindMilestoneOptions`. Fixes: https://github.com/go-gitea/gitea/issues/39150 Co-authored-by: silverwind <[email protected]>

• Léon Simmons(23 Oct 26)

  docs: fix typos in code comments (#39968) - `models/asymkey/error.go`: `IsErrGPGKeyIDAlreadyUsed` doc named the wrong type (`ErrKeyNameAlreadyUsed` → `ErrGPGKeyIDAlreadyUsed`) - `modules/lfs/http_client.go`: `batchs` → `batches` - `routers/web/repo/milestone.go`: `edting` → `editing` (x2), `for change` → `for changing` Signed-off-by: Léon Avic Simmons <[email protected]>

• Lunny Xiao(23 Oct 26)

  feat(migrations): add migration from Bitbucket Server (Data Center) (#39913) Add migration from Bitbucket Server (Data Center). It has no issues, wiki, milestones or releases, so those are not offered. Migrated: git data with tags and LFS, and pull requests with state, draft flag, merge commit/base, comments, approvals and inline code comments including resolved threads. Multi-line ranges become a `Lines a-b:` text prefix, as Gitea anchors code comments to one line. Auth is an HTTP access token (personal, project or repository) or username/password; 429 responses are retried. Changes outside the downloader: - `ReviewComment.Resolved`, applied by the uploader. - The uploader creates a fork PR's head branch from its head commit when already in the repository, instead of fetching the fork (Bitbucket keeps it in `refs/pull-requests/<id>/from`; private forks need credentials). Tested with unit tests, responses recorded from Bitbucket 10.5.1, and an end-to-end migration. Independent of https://github.com/go-gitea/gitea/pull/38607 (Bitbucket Cloud); the service type enum value needs adjusting for whichever lands second. --------- Co-authored-by: bircni <[email protected]>

• silverwind(23 Oct 26)

  ci(release): stop creating deployments for release tags (#39966) Each `release-create-tag` run created a deployment record, which makes GitHub show a useless "This branch has not been deployed" box on every PR: <img width="819" height="113" alt="image" src="https://github.com/user-attachments/assets/129c8348-1d70-46b9-8996-8872c84a11f2" /> With `deployment: false`, the `release-signing` approval and branch policy still apply.

• silverwind(23 Oct 26)

  fix: correctly parse and validate forwarded client IPs and remove unmaintained `chi-middleware/proxy` (#39190) Replace the unmaintained `chi-middleware/proxy` with an in-tree handler that detects client IPs correctly behind common reverse proxies. 1. Handle repeated header lines and comma-separated proxy hops. 2. Accept and normalize IPs, including `ip:port`. 3. Keep the client port from the header value or `X-Real-Port` instead of logging port 0. 4. Prefer the last `X-Real-IP` line. 5. Keep the proxy's address when the selected value is invalid. 6. Read `Forwarded` only when `X-Forwarded-For` is absent. Docs PR: https://gitea.com/gitea/docs/pulls/560 Fixes: https://github.com/go-gitea/gitea/issues/35682 Fixes: https://github.com/go-gitea/gitea/issues/36814 Co-authored-by: bircni <[email protected]>

• Lunny Xiao(23 Oct 26)

  perf(actions): cache successful runner token verification (#39934) Every Actions runner RPC (`FetchTask` polling, `UpdateTask`, `UpdateLog`, ...) goes through the `withRunner` interceptor, which verifies the runner token with PBKDF2 (`auth_model.HashToken`, ~2 ms). In a 60s CPU profile of a production instance with many runners, this accounted for ~49% of all CPU samples. - Cache successful verifications in a dedicated LRU of up to 10000 runners, keyed by the stored salt and hash and holding only a SHA-256 digest of the token. A hit costs ~100 ns. - The runner is still loaded from the DB on every RPC and failures are never cached, so deleted runners and wrong tokens never pass. - The shared `auth_model.TokenCache` is not used because its default 20 entries miss on every poll once more runners poll in turn. --------- Co-authored-by: silverwind <[email protected]>

• David Lovas(23 Oct 26)

  feat(migrations): GraphQL fast path for GitHub migration + rate-limit resilience (#38694) Adds a batched GraphQL path for GitHub migrations that fetches each issue or pull request together with its comments, reviews, reactions and timeline events instead of the REST N+1 pattern, sharply reducing rate-limit pressure on large repositories. - GraphQL is used for authenticated migrations with issues or pull requests and falls back to REST automatically when it fails - timeline events (close/reopen, lock, rename, label, milestone, merge, branch deletion, pin, auto-merge) are imported as typed comments showing their GitHub author - GitBucket issue migrations no longer stop after the first page, GitBucket sends no Link header Fixes: https://github.com/go-gitea/gitea/issues/13243 Fixes: https://github.com/go-gitea/gitea/issues/31856 Signed-off-by: David E. Lovas <[email protected]> Co-authored-by: bircni <[email protected]> Co-authored-by: silverwind <[email protected]> Co-authored-by: Giteabot <[email protected]>

• Lunny Xiao(23 Oct 26)

  feat: Allow automatic project actions on events (#30205) This PR introduces project workflows, allowing users to configure event-based automations directly from the UI. Users can define filters and actions for each workflow event, and duplicate existing events when needed. ### Concepts Every workflow is composed of `event`, `filters`, and `actions`. - **Event** - An Event defines when a workflow should be triggered. It represents specific activities such as an issue being added to the project, a pull request being merged, or a project column being changed. - **Filter** - A Filter refines when an event should take effect. It allows users to specify conditions like issue type, labels, or project columns to ensure actions only run in targeted scenarios. - **Action** - An Action defines what happens when the event and filters match. It performs operations such as adding labels, moving issues between columns, or changing the issue or pull request state. ### Available Events Currently, the following eight events are supported: - On issues/pull requests closed - On issues/pull requests reopened - On issues/pull requests was added to the project, including when created in it - On issues/pull requests was removed from the project - On issues/pull requests' column was changed - On code changes requested - On code review approved - On pull request merged Each event type supports its own set of filters and actions. ### Available Filters There are four types of filters that can be configured for an event: - **Apply to** - Specify the target type: `issues only`, `pull requests only`, or `issues and pull requests`. - **Labels** - Trigger the event only if the issue or pull request contains one or more specified labels. - **Move from column** - Filter events based on the original project column. - **Move to column** - Filter events based on the destination project column. ### Available Actions There are four types of actions that can be executed when an event is triggered: - **Add labels** - Automatically add one or more labels to the issue or pull request. - **Remove labels** - Remove one or more specified labels. - **Move to column** - Move the issue or pull request to a designated project column. - **Issue state** - Close or reopen the issue. Pull requests can only be closed. ### Enable/Disable an event workflow Each event workflow can be individually enabled or disabled. When disabled, the workflow will be ignored even if the event occurs. This feature is useful when you want to temporarily stop certain automated actions without deleting the workflow configuration. Workflows of closed projects don't run either. ### Clone an event workflow When you need multiple workflows for the same event, you can clone an existing event to create a new one with different filters and actions. This allows you to customize how the same event behaves under different conditions, making workflows more flexible and powerful. ### Permissions Permissions are checked when workflows are managed, not when they run: - Viewing a project's workflows needs read access to the project - Managing them needs write access to the project plus write access to both issues and pull requests of a repository project's repository, being an owner of an organization project's organization or a site administrator, or being the user of a user project. Tokens limited to public repositories can't manage owner-level projects' workflows - A workflow runs when its event happens to an item of an open project that can hold the item's repository, unless that repository is archived, no matter who caused the event, and applies its actions without further permission checks. Pull requests are never reopened - Changes show as made by "Project workflow" on behalf of the user who triggered the event and don't trigger other workflows - Only users who can read an item can put it on a board or move its card The management rule is also documented on `CanManageWorkflows` in `services/projects/workflow.go`. Fixes: #14359 Fixes: #26704 Fixes: #27990 Replaces: #28745 Documentation PR: https://gitea.com/gitea/docs/pulls/308 Co-authored-by: bircni <[email protected]> Co-authored-by: silverwind <[email protected]> Co-authored-by: Giteabot <[email protected]>

• GiteaBot(23 Oct 26)

  [skip ci] Updated translations via Crowdin

• silverwind(22 Oct 26)

  docs: clarify that the team packages permission covers all org packages (#39953) The Packages row in the team settings read "Manage repository packages.", but packages belong to the owner, so a team's Packages permission applies to every package of the organization, regardless of the team's repositories. Reword it to say so. The docs get the same clarification in https://gitea.com/gitea/docs/pulls/605.

• silverwind(22 Oct 26)

  ci: update giteabot to v1.3.1 (#39947) Bump `giteabot` to [`v1.3.1`](https://github.com/go-gitea/giteabot/releases/tag/v1.3.1) in both workflows. It fixes `reviewed/wait-merge` PRs that the merge queue left behind their base, like https://github.com/go-gitea/gitea/pull/39854 and https://github.com/go-gitea/gitea/pull/39928, and stops the lgtm sweep from re-posting unchanged statuses (https://github.com/go-gitea/giteabot/pull/30).

• silverwind(22 Oct 26)

  chore: sync pnpm engines version with packageManager (#39950) The pnpm `engines` range was still `>= 11.0.0` while `packageManager` is on pnpm 12. Raise it to match, and set Renovate's range strategy for it to `bump`, because the default strategy leaves an already satisfied `>=` range untouched.

• Josway(22 Oct 26)

  fix(ui): commit hashes in the activity feed are misaligned (#39883) Fixes #38646 ### The problem Each commit line of a push in the activity feed starts with the avatar stack of its co-authors. The width of that stack grows with the number of co-authors, so the hash of every commit started at a different horizontal offset and the column looked ragged. --------- Signed-off-by: Josway <[email protected]> Co-authored-by: silverwind <[email protected]>

• Nazem(22 Oct 26)

  fix(api): adding issue labels by name attaches both the repo and the org label (#39873) Fixes #39651 When an org-owned repo has a repo label and an org label with the same name, `POST`/`PUT /repos/{owner}/{repo}/issues/{index}/labels` with label names attached both of them. --------- Signed-off-by: Nazem <[email protected]> Co-authored-by: Nazem <[email protected]> Co-authored-by: silverwind <[email protected]>

• Basavaraj S m(22 Oct 26)

  fix(feed): hide release notes in tags feed without releases access (#39944) The tags feed (`tags.rss` / `tags.atom`) lives in the tags route group, which only requires code read access, yet it lists every published release next to the plain tags and includes each release's title and rendered note. The releases page and `releases.rss` require releases read access, and the tags page only shows tag names to users without it, so the feed is the one place that leaks. A team member granted Code but not Releases on a private repo, or anyone on a public repo whose Releases unit is disabled, can read all release notes this way. I noticed it while comparing the feed routes with the tags template. When the doer cannot read releases, the feed now lists releases as plain tags, linking to `/src/tag/` like the tags page does.

• Chris Eastwood(22 Oct 26)

  build(tools): install playwright deps only when that needs no prompt (#39905) On Debian/Ubuntu outside GitHub Actions, `tools/playwright.sh` always ran `pnpm exec playwright install --with-deps`. Installing system packages needs root: when it isn't root, Playwright tries `sudo` and falls back to `su`, so a non-root user without passwordless sudo sees `make playwright` — and the targets depending on it, `make test-e2e` and `make test-frontend` — either stop and ask for the root password mid-build or fail outright with `su: System error`. Related: #38860, which added this script. --------- Co-authored-by: silverwind <[email protected]>

• bircni(22 Oct 26)

  fix(actions): bound requested artifact retention (#39894)

• bircni(22 Oct 26)

  docs: clarify reverse proxy authentication requirements (#39940) Document that reverse proxy authentication requires Gitea to be reachable only through the authenticating proxy, and which routes each setting covers. Docs: https://gitea.com/gitea/docs/pulls/604 Co-authored-by: silverwind <[email protected]>

• silverwind(22 Oct 26)

  enhance: remove box-shadow from kbd elements (#39943) Remove the inset bottom shadow from `<kbd>` elements in markup and on keyboard shortcut hints. The skeuomorphic key cap look is not needed, the border alone marks the element as a key.

• silverwind(22 Oct 26)

  refactor: prevent out-of-bounds read (#39936) `IsReadmeFileExtension("readme", exts...)` panicked with `index out of range [6] with length 6` when `exts` had no empty extension. The only caller always passes one, so this was not reachable in practice. Fixes: https://github.com/go-gitea/gitea/security/quality/rules/go%2Findex-out-of-bounds Written by Claude.

• Phoenix(22 Oct 26)

  fix(migrations): use cursor pagination for GitHub issue migration too (#39888) For repos with many issues, the GitHub API only allows cursor-based pagination instead of page-based pagination after a certain page. A full migration of such repos failed with a 422 response. Now, we dynamically switch how we migrate based on the response from the GitHub API. Fixes #39882 --------- Signed-off-by: Phoenix <[email protected]> Co-authored-by: delvh <[email protected]> Co-authored-by: silverwind <[email protected]>