Partially fix#32018
`git config` and `git remote` write operations create a temporary file
named `config.lock`. Since these operations are not atomic, they must
not be run in parallel. If two requests attempt to modify the same
repository concurrently—such as during a compare operation—one may fail
due to the presence of an existing `config.lock` file.
In cases where `config.lock` is left behind due to an unexpected program
exit, a global lock mechanism could allow us to safely remove the stale
lock file when a related error is detected. While this behavior is not
yet implemented in this PR, it is planned for a future enhancement.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
similar to how we can enable/disable repos or issues on a repo add the
code unit as option to it.
affects
```
PATCH /repos/{owner}/{repo}
```
---
*Sponsored by Kithara Software GmbH*
Issue: https://github.com/go-gitea/gitea/issues/9637
Changes introduced: I have clarified the problematic terms (owner and
parent) in all affected endpoints.
The changes were made to relevant:
- HTTP endpoint parameters' descriptions
- response/request models' fields
This MR is big, but most changes are the same. If you'd like me to break
this MR into several smaller ones, let me know :)
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Change the OpenAPI response of `ListWorkflowRuns` to `WorkflowRunsList`
like it is supposed to be.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
This PR fixes the response format for the OpenAPI Spec of
`ActionsListRepositoryWorkflows`.
It was specified in the OpenAPI spec as returning a `[]*ActionWorkflow`,
but it actually should return a `api.ActionWorkflowResponse`.
The test already expects an `api.ActionWorkflowResponse` like expected.
Issue: [link](https://github.com/go-gitea/gitea/issues/9637)
Changes introduced: I have clarified the problematic terms (`login`,
`login_name`, and `username`) in all affected endpoints.
The changes were made to relevant:
- HTTP endpoint parameters' descriptions
- response/request models' fields
enable nolintlint scope requirement
add comments to new directives so it's more obvious why they are in
place
---
I can also toggle the mandatory comments on if that's something of
interest.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Follow up the "editor" refactor, use the same approach to simplify code,
and fix some docs & comments
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
This PR fixes a state de-synchronization bug with the issue stopwatch,
it resolves the issue by replacing the ambiguous `/toggle` endpoint
with two explicit endpoints: `/start` and `/stop`.
- The "Start timer" button now exclusively calls the `/start` endpoint.
- The "Stop timer" button now exclusively calls the `/stop` endpoint.
This ensures the user's intent is clearly communicated to the server,
eliminating the state inconsistency and fixing the bug.
---------
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
The merge-upstream route was so far performing any kind of merge, even
those that would create merge commits and thus make your branch diverge
from upstream, requiring manual intervention via the git cli to undo the
damage.
With the new optional parameter ff_only, we can instruct gitea to error
out, if a non-fast-forward merge would be performed.
This adds a new field, "tag_message", that represents the message of the
annotated tag.
Resolves#31835.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
* Signed SSH commits can look in the UI like on GitHub, just like gpg keys today in Gitea
* SSH format can be added in gitea config
* SSH Signing worked before with DEFAULT_TRUST_MODEL=committer
`TRUSTED_SSH_KEYS` can be a list of additional ssh public key contents
to trust for every user of this instance
Closes#34329
Related #31392
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
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
Similar to #34544, this PR changes the `opts` argument in
`SearchRepositoryByName()` to be passed by value instead of by pointer,
as its mutations do not escape the function scope and are not used
elsewhere. This simplifies reasoning about the function and avoids
unnecessary pointer usage.
This insight emerged during an initial attempt to refactor
`RenderUserSearch()`, which currently intermixes multiple concerns.
---------
Co-authored-by: Philip Peterson <philip-peterson@users.noreply.github.com>
This PR changes the `opts` argument in `SearchUsers()` to be passed by
value instead of by pointer, as its mutations do not escape the function
scope and are not used elsewhere. This simplifies reasoning about the
function and avoids unnecessary pointer usage.
This insight emerged during an initial attempt to refactor
`RenderUserSearch()`, which currently intermixes multiple concerns.
Co-authored-by: Philip Peterson <philip-peterson@users.noreply.github.com>
- Change CreateVariable API response status from 204 No Content to 201
Created
- Update related integration tests to expect 201 Created instead of 204
No Content
## ⚠️ BREAKING ⚠️
Change the response status code of the Create Variable API under both
Org and Repo levels to `201` instead of 204.
API SDK: https://gitea.com/gitea/go-sdk/pulls/713
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Signed-off-by: appleboy <appleboy.tw@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
- 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>
