- Add support for filtering commits by date range via new "since" and
"until" parameters
- Update API endpoints and command logic to handle the new parameters
for fetching commits within given dates
- Extend API documentation and Swagger specs to describe the new "since"
and "until" query parameters
- Refactor related function signatures and implementations to accept and
pass "since" and "until" values
---------
Signed-off-by: appleboy <appleboy.tw@gmail.com>
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
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
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>
* fixes a fixture status to upload confirmed
* add another fixture as noise to break tests as soon they are exposed
to api
* v4 delete test added check that artifact is no longer visible in
internal api with status pending delete
* removal of http 404 on empty list: actions/upload-artifact@v4 now
backoff on http 404 of ListArtifacts endpoint
* fixes artifacts with pending delete etc. are able to be found and
downloaded if the storage is not freed
`[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>
