6 commits

Author	SHA1	Message	Date
Earl Warren	69bedb8933	Merge pull request 'fix: correct documentation for non 200 responses in swagger' (#5491) from JakobDev/forgejo:fixswagger into forgejo ... Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5491 Reviewed-by: Otto <otto@codeberg.org>	2024-10-15 11:34:35 +00:00
Lunny Xiao	a052d2b602	Fix bug when a token is given public only ... Port of https://github.com/go-gitea/gitea/pull/32204 (cherry picked from commit d6d3c96e6555fc91b3e2ef21f4d8d7475564bb3e) Conflicts: routers/api/v1/api.go services/context/api.go trivial context conflicts	2024-10-10 10:41:42 +03:00
JakobDev	fcc3dd228d	fix: correct documentation for non 200 responses in swagger	2024-10-07 18:36:07 +02:00
Gusted	bf0d100b84	[CHORE] Move cache library ... - This is in the spirit of #5090. - Move to a fork of gitea.com/go-chi/cache, code.forgejo.org/go-chi/cache. It removes unused code (a lot of adapters, that can't be used by Forgejo) and unused dependencies (see go.sum). Also updates existing dependencies. 8c64f1a362..main	2024-08-27 21:28:56 +02:00
Gergely Nagy	e1fe3bbdc0	feat(quota): Humble beginnings of a quota engine ... This is an implementation of a quota engine, and the API routes to manage its settings. This does *not* contain any enforcement code: this is just the bedrock, the engine itself. The goal of the engine is to be flexible and future proof: to be nimble enough to build on it further, without having to rewrite large parts of it. It might feel a little more complicated than necessary, because the goal was to be able to support scenarios only very few Forgejo instances need, scenarios the vast majority of mostly smaller instances simply do not care about. The goal is to support both big and small, and for that, we need a solid, flexible foundation. There are thee big parts to the engine: counting quota use, setting limits, and evaluating whether the usage is within the limits. Sounds simple on paper, less so in practice! Quota counting ============== Quota is counted based on repo ownership, whenever possible, because repo owners are in ultimate control over the resources they use: they can delete repos, attachments, everything, even if they don't *own* those themselves. They can clean up, and will always have the permission and access required to do so. Would we count quota based on the owning user, that could lead to situations where a user is unable to free up space, because they uploaded a big attachment to a repo that has been taken private since. It's both more fair, and much safer to count quota against repo owners. This means that if user A uploads an attachment to an issue opened against organization O, that will count towards the quota of organization O, rather than user A. One's quota usage stats can be queried using the `/user/quota` API endpoint. To figure out what's eating into it, the `/user/repos?order_by=size`, `/user/quota/attachments`, `/user/quota/artifacts`, and `/user/quota/packages` endpoints should be consulted. There's also `/user/quota/check?subject=<...>` to check whether the signed-in user is within a particular quota limit. Quotas are counted based on sizes stored in the database. Setting quota limits ==================== There are different "subjects" one can limit usage for. At this time, only size-based limits are implemented, which are: - `size:all`: As the name would imply, the total size of everything Forgejo tracks. - `size:repos:all`: The total size of all repositories (not including LFS). - `size:repos:public`: The total size of all public repositories (not including LFS). - `size:repos:private`: The total size of all private repositories (not including LFS). - `sizeall`: The total size of all git data (including all repositories, and LFS). - `sizelfs`: The size of all git LFS data (either in private or public repos). - `size:assets:all`: The size of all assets tracked by Forgejo. - `size:assets:attachments:all`: The size of all kinds of attachments tracked by Forgejo. - `size:assets:attachments:issues`: Size of all attachments attached to issues, including issue comments. - `size:assets:attachments:releases`: Size of all attachments attached to releases. This does *not* include automatically generated archives. - `size:assets:artifacts`: Size of all Action artifacts. - `size:assets:packages:all`: Size of all Packages. - `size:wiki`: Wiki size Wiki size is currently not tracked, and the engine will always deem it within quota. These subjects are built into Rules, which set a limit on *all* subjects within a rule. Thus, we can create a rule that says: "1Gb limit on all release assets, all packages, and git LFS, combined". For a rule to stand, the total sum of all subjects must be below the rule's limit. Rules are in turn collected into groups. A group is just a name, and a list of rules. For a group to stand, all of its rules must stand. Thus, if we have a group with two rules, one that sets a combined 1Gb limit on release assets, all packages, and git LFS, and another rule that sets a 256Mb limit on packages, if the user has 512Mb of packages, the group will not stand, because the second rule deems it over quota. Similarly, if the user has only 128Mb of packages, but 900Mb of release assets, the group will not stand, because the combined size of packages and release assets is over the 1Gb limit of the first rule. Groups themselves are collected into Group Lists. A group list stands when *any* of the groups within stand. This allows an administrator to set conservative defaults, but then place select users into additional groups that increase some aspect of their limits. To top it off, it is possible to set the default quota groups a user belongs to in `app.ini`. If there's no explicit assignment, the engine will use the default groups. This makes it possible to avoid having to assign each and every user a list of quota groups, and only those need to be explicitly assigned who need a different set of groups than the defaults. If a user has any quota groups assigned to them, the default list will not be considered for them. The management APIs =================== This commit contains the engine itself, its unit tests, and the quota management APIs. It does not contain any enforcement. The APIs are documented in-code, and in the swagger docs, and the integration tests can serve as an example on how to use them. Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>	2024-08-02 11:10:34 +02:00
Lunny Xiao	894d9b2836	Move context from modules to services (#29440) ... Since `modules/context` has to depend on `models` and many other packages, it should be moved from `modules/context` to `services/context` according to design principles. There is no logic code change on this PR, only move packages. - Move `code.gitea.io/gitea/modules/context` to `code.gitea.io/gitea/services/context` - Move `code.gitea.io/gitea/modules/contexttest` to `code.gitea.io/gitea/services/contexttest` because of depending on context - Move `code.gitea.io/gitea/modules/upload` to `code.gitea.io/gitea/services/context/upload` because of depending on context (cherry picked from commit 29f149bd9f517225a3c9f1ca3fb0a7b5325af696) Conflicts: routers/api/packages/alpine/alpine.go routers/api/v1/repo/issue_reaction.go routers/install/install.go routers/web/admin/config.go routers/web/passkey.go routers/web/repo/search.go routers/web/repo/setting/default_branch.go routers/web/user/home.go routers/web/user/profile.go tests/integration/editor_test.go tests/integration/integration_test.go tests/integration/mirror_push_test.go trivial context conflicts also modified all other occurrences in Forgejo specific files	2024-03-06 12:10:43 +08:00

Renamed from modules/context/api.go (Browse further)