- Backport #19652
- Don't use hacky solution to limit to the correct RepoID's, instead use current code to handle these limits. The existing code is more correct than the hacky solution.
- Resolves#19636
Co-authored-by: Loïc Dachary <loic@dachary.org>
(cherry picked from commit b536b65189)
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>
Сергей Аксенов
Алексей Безбородов
Gitea
Lunny Xiao
Gusted
6543
singuliere
Jimmy Praet
techknowlogick
zeripath
wxiaoguang
Eekle
99rgosse