Backport #34509 by @lunny
If user leaves the page, the context will become cancelled, so that the
update process maybe terminal in an unexpected status. This PR haven't
resolve the problem totally. It uses a background context to not cancel
the update process even if the user leaved the pull request view page.
Fix#31779
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #34525 by @MarkusAmshove
closes#34171
Adds a new sort option `recentclose` for issues and pull requests which
will return items in a descending order of when they were closed
Co-authored-by: Markus Amshove <scm@amshove.org>
Backport #34480 by @ChristopherHX
* previously deleting an already deleted runner returned http 500
* previously any database error for the get endpoint was http 404 and
never 500
Co-authored-by: ChristopherHX <christopher.homberger@web.de>
Backport #34323 by @tobiasbp
In the Gitea GUI, the user can see the time that _AccessTokens_ and
_PublicKeys_ were last used. This information is not returned by the
_/users/{username}/tokens_ and _/user/keys_ endpoints in the API. This
PR adds the missing data.
The time of last usage for for _tokens_ & _keys_ seem to be stored in
the _Updated_ field of the structs internally. For consistency, I have
used the name _updated_at_ for the new field returned by the _API_.
However, for the _API_ user, I don't think that name reflects the data
returned, as I believe it is the time of last usage. I propose that we
use the name _last_used_at_ instead. Let's hear reviewers opinion on
that.
* PublicKey
1. _last_used_at_: string($date-time)
* AccessToken
1. _created_at_: string($date-time) (for parity with public keys)
2. _last_used_at_: string($date-time)
Fix#34313
Co-authored-by: Tobias Balle-Petersen <tobiasbp@gmail.com>
Fix#880
Design:
1. A global setting `security.TWO_FACTOR_AUTH`.
* To support org-level config, we need to introduce a better "owner
setting" system first (in the future)
2. A user without 2FA can login and may explore, but can NOT read or
write to any repositories via API/web.
3. Keep things as simple as possible.
* This option only aggressively suggest users to enable their 2FA at the
moment, it does NOT guarantee that users must have 2FA before all other
operations, it should be good enough for real world use cases.
* Some details and tests could be improved in the future since this
change only adds a check and seems won't affect too much.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
`[repository.pull-request] DELAY_CHECK_FOR_INACTIVE_DAYS` is a new
setting to delay the mergeable check for pull requests that have been
inactive for the specified number of days.
This avoids potentially long delays for big repositories with many pull
requests. and reduces system load overall when there are many
repositories or pull requests.
When viewing the PR, checking will start immediately and the PR merge
box will automatically reload when complete. Accessing the PR through
the API will also start checking immediately.
The default value of `7` provides a balance between system load, and
keeping behavior similar to what it was before both for users and API
access. With `0` all conflict checking will be delayed, while `-1`
always checks immediately to restore the previous behavior.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Adds an API POST endpoint under `/repos/{owner}/{repo}/file-contents`
which receives a list of paths and returns a list of the contents of
these files.
This API endpoint will be helpful for applications like headless CMS
(reference: https://github.com/sveltia/sveltia-cms/issues/198) which
need to retrieve a large number of files by reducing the amount of
needed API calls.
Close#33495
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This pull request adds a GitHub-compatible API endpoint to lock and
unlock an issue.
The following routes exist now:
- `PUT /api/v1/repos/{owner}/{repo}/issues/{id}/lock` to lock an issue
- `DELETE /api/v1/repos/{owner}/{repo}/issues/{id}/lock` to unlock an issue
Fixes#33677Fixes#20012
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Implements runner apis based on
https://docs.github.com/en/rest/actions/self-hosted-runners?apiVersion=2022-11-28#list-self-hosted-runners-for-an-organization
- Add Post endpoints for registration-token, google/go-github revealed
this as problem
- We should deprecate Get Endpoints, leaving them for compatibility
- Get endpoint of admin has api path /admin/runners/registration-token
that feels wrong, /admin/actions/runners/registration-token seems more
consistent with user/org/repo api
- Get Runner Api
- List Runner Api
- Delete Runner Api
- Tests admin / user / org / repo level endpoints
Related to #33750 (implements point 1 and 2)
Via needs discovered in #32461, this runner api is needed to allow
cleanup of runners that are deallocated without user interaction.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fixes#33544
Adds two new api endpoints to list a versions of a package and to get
the latest version of a package by API.
⚠️ BREAKING ⚠️
the `size` field for this endpoint changes from `Size` to `size`.
Allows admins and org owners to change org member public status.
Before, this would return `Error 403: Cannot publicize another member`
despite the fact that the same user could make the same change through
the GUI.
Fixes#28372
---------
Co-authored-by: Tomáš Ženčák <zencak@ica.cz>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Extract from #33934
In the same goroutine, we should reuse the exist cat file sub process
which exist in `git.Repository` to avoid creating a unnecessary
temporary subprocess.
This PR reuse the exist cate file writer and reader in
`getCommitFromBatchReader`.
It also move `prepareLatestCommitInfo` before creating dataRc which will
hold the writer so other git operation will create a temporary cat file
subprocess.
* Fix#33972
* Use consistent path resolving for links and medias.
* No need to make the markup renders to resolve the paths, instead, the
paths are all correctly resolved in the "post process" step.
* Fix#33274
* Since 1.23, all paths starting with "/" are relative to current render
context (for example: the current repo branch)
* Introduce `/:root/path-relative-to-root`, then the path will be
rendered as relative to "ROOT_URL"
Fix#33966
```
;; User must sign in to view anything.
;; It could be set to "expensive" to block anonymous users accessing some pages which consume a lot of resources,
;; for example: block anonymous AI crawlers from accessing repo code pages.
;; The "expensive" mode is experimental and subject to change.
;REQUIRE_SIGNIN_VIEW = false
```
Fix#33358, fix#21970
This adds a step in the `GitDiffForRender` that does syntax highlighting for the
entire file and then only references lines from that syntax highlighted
code. This allows things like multi-line comments to be syntax
highlighted correctly.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The diff stats are no longer part of the diff generation.
Use `GetDiffShortStat` instead to get the total number of changed files,
added lines, and deleted lines.
As such, `gitdiff.GetDiff` can be simplified:
It should not do more than expected.
And do not run "git diff --shortstat" for pull list. Fix#31492
1. GetUserOrgsList should "order by" lower_name
2. GetIssuePostersWithSearch should search in-case-sensitive-ly
3. LoginName should not be used as username
By the way, remove unnecessary "onGiteaRun"
Noticed a SQL in gitea.com has a bigger load. It seems both `is_pull`
and `pin_order` are not indexed columns in the database.
```SQL
SELECT `id`, `repo_id`, `index`, `poster_id`, `original_author`, `original_author_id`, `name`, `content`, `content_version`, `milestone_id`, `priority`, `is_closed`, `is_pull`, `num_comments`, `ref`, `pin_order`, `deadline_unix`, `created_unix`, `updated_unix`, `closed_unix`, `is_locked`, `time_estimate` FROM `issue` WHERE (repo_id =?) AND (is_pull = 0) AND (pin_order > 0) ORDER BY pin_order
```
I came across a comment
https://github.com/go-gitea/gitea/pull/24406#issuecomment-1527747296
from @delvh , which presents a more reasonable approach. Based on this,
this PR will migrate all issue and pull request pin data from the
`issue` table to the `issue_pin` table. This change benefits larger
Gitea instances by improving scalability and performance.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
