Co-authored-by: Loïc Dachary <loic@dachary.org>
(cherry picked from commit b536b65189319544939da9b6537919a4fc838d71)
Conflicts:
models/action_test.go
The GetFeeds function does not have a Context argument in 1.16.
models/action.go
The SQL statement is essentially the same in 1.16 but
structured differently. The Join() was copied and the
created_unix field prefixed with `action`.
models/action_list.go
in 1.16 the loadRepoOwner method did not exist and
it was done in the RetrieveFeeds method of web/feed/profile.go.
The safeguard to skip when act.Repo == nil was moved there.
Our drone by necessity runs on git repositories not owned by the drone process. Unfortunately this means that git operations and thence CI builds will fail without the `safe.directory` option being set.
See: https://drone.gitea.io/go-gitea/gitea/54632/2/8
It may be prudent to add runtime finalizers to the git.Repository and
git.blobReader objects to absolutely ensure that these are both properly
cancelled, cleaned and closed out.
This commit is a backport of an extract from #19448
Signed-off-by: Andrew Thornton <art27@cantab.net>
- Backport #19547
- If one of the branches no longer exists, don't throw an error, it's possible that the branch was destroyed during the process. Simply skip it and disregard it.
- Resolves#19541
Backport #19537
There is a potential rare race possible whereby the c.running channel could
be closed twice. Looking at the code I do not see a need for this c.running
channel and therefore I think we can remove this. (I think the c.running
might have been some attempt to prevent a hang but the use of os.Pipes should
prevent that.)
Signed-off-by: Andrew Thornton <art27@cantab.net>
- Backport #19531
- Doing 64-bit atomic operations on 32-bit machines is a bit tricky by golang, as they can only be done under certain set of conditions(https://pkg.go.dev/sync/atomic#pkg-note-BUG).
- This PR fixes such case whereby the conditions weren't met, it moves the int64 to the first field of the struct, which will 64-bit operations happening on this property on 32-bit machines.
- Resolves#19518
Backport #19516
Within doArchive there is a service goroutine that performs the
archiving function. This goroutine reports its error using a `chan
error` called `done`. Prior to this PR this channel had 0 capacity
meaning that the goroutine would block until the `done` channel was
cleared - however there are a couple of ways in which this channel might
not be read.
The simplest solution is to add a single space of capacity to the
goroutine which will mean that the goroutine will always complete and
even if the `done` channel is not read it will be simply garbage
collected away.
(The PR also contains two other places when setting up the indexers
which do not leak but where the blocking of the sending goroutine is
also unnecessary and so we should just add a small amount of capacity
and let the sending goroutine complete as soon as it can.)
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: 6543 <6543@obermui.de>
TestAPIGitTag (and likely others) will fail if the running environment contains
GIT_AUTHOR_NAME and other env variables like it.
This PR simply unsets these when running the integration tests.
Fix#14247
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: zeripath <art27@cantab.net>
* Mark TemplateLoading error as "UnprocessableEntity" (#19445)
- Backport #19445
- Don't return Internal Server error if the user provide incorrect label template, instead return UnprocessableEntity.
- Resolves#19399
- dep: upgrade: github.com/gogs/chardet
If an `os/exec.Command` is passed non `*os.File` as an input/output, go
will create `os.Pipe`s and wait for their closure in `cmd.Wait()`. If
the code following this is responsible for closing `io.Pipe`s or other
handlers then on process death from context cancellation the `Wait` can
hang.
There are two possible solutions:
1. use `os.Pipe` as the input/output as `cmd.Wait` does not wait for these.
2. create a goroutine waiting on the context cancellation that will close the inputs.
This PR provides the second option - which is a simpler change that can
be more easily backported.
Closes#19448
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: zeripath <art27@cantab.net>
- Backport #19457
- When 3-way merge is enabled for conflict checking, it has a new interesting behavior that it doesn't return any error when it found a conflict, so we change the condition to not check for the error, but instead check if conflictedfiles is populated, this fixes a issue whereby PR status wasn't correctly on conflicted PR's.
- Refactor the mergeable property(which was incorrectly set and lead me this bug) to be more maintainable.
- Add a dedicated test for conflicting checking, so it should prevent future issues with this.
- Ref: Fix the latest error for https://gitea.com/gitea/go-sdk/pulls/579
Co-authored-by: zeripath <art27@cantab.net>
* When dumping trim the standard suffices instead of a random suffix
Instead of using the `path.Ext()` to trim the last "extension" suffix, just iterate
through the supported suffices and trim those.
Fix#19424
Signed-off-by: Andrew Thornton <art27@cantab.net>
* fix enum with to have correct supported types only
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>
- Backport #19443
- Add a return for the first "block" of errors, which fixes the double error messages.
- Add a return for `externallyManaged`.
- Resolves#19398
Co-authored-by: 6543 <6543@obermui.de>
- Backport #19441
- Don't panic on `ErrEmailInvalid`, this was caused due that we were trying to force `ErrEmailCharIsNotSupported` interface, which panics.
- Resolves#19397
Co-authored-by: 6543 <6543@obermui.de>
Older git clients need uploadpack.allowAnySHA1InWant if partial cloning is allowed.
Fix#19118
Signed-off-by: Andrew Thornton <art27@cantab.net>
Co-authored-by: zeripath <art27@cantab.net>
Backport #19317
- Warn on SSH connection for incorrect configuration
- When `setting.RepoRootPath` cannot be found(most likely due to
incorrect configuration) show "Gitea: Incorrect configuration" on the
client-side to help easier with debugging the problem.
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Backport #19244
* remove error who is none
* use setupSessionNoLimit instead of setupSessionWithLimit when no pagination
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #19429
When a mirror repo interval is updated by the UI it is rescheduled with that interval
however the API does not do this. The API also lacks the enable_prune option.
This PR adds this functionality in to the API Edit Repo endpoint.
Signed-off-by: Andrew Thornton <art27@cantab.net>
* Don't allow merging PR's which are being conflict checked (#19357)
- Backport of #19357
- When a PR is still being conflict checked, don't allow the PR to be merged(the merge button could already be visible before e.g. a new commit was pushed to the PR).
- Resolves#19352
* Update error message
- Backport #19377
- Add reqSignIn to `/user/task/{task}` as it specific to a logged in user currently not-logged in user could cause a NPE.
- Remove `/user/active` reqSignIn middleware, because when you want to active a account you're not "signed in" so it doesn't make sense to add that middleware.
The service worker causes a lot of issues with JS errors after instance
upgrades while not bringing any real performance gain over regular HTTP
caching.
Disable it by default for this reason. Maybe later we can remove it
completely, as I simply see no benefit in having it.
There was a bug that the CSRF token wouldn't in 24h. This fix just does what the CSRF function comment says: If this request is a GET request, it will generate a new token. Then the CSRF token can be kept up-to-date.
