Backport #30357 by @yp05327
When repo is a mirror, and commit author is an external user, then
`GetUserByEmail` will return error.
reproduce/test:
- mirror Gitea to your instance
- disable action and enable it again, this will trigger
`DetectAndHandleSchedules`
ps: also follow #24706, it only fixed normal runs, not scheduled runs.
Co-authored-by: yp05327 <576951401@qq.com>
Fix#30361, regression of #29782 which is a backport, not the original
#29468.
#29468 did a small refactor which introduced a new function
`GetVariablesOfRun`. However, it's designed for v1.22 which supports
global variables.
After backporting it to v1.21, it will still try to get global
variables, which causes it to retrieve all variables.
Backport #30245 by @KN4CK3R
Fixes#30235
If the key id "front" byte has a single digit, `%X` is missing the 0
prefix.
` 38D1A3EADDBEA9C` instead of
`038D1A3EADDBEA9C`
When using the `IssuerFingerprint` slice `%X` is enough but I changed it
to `%016X` too to be consistent.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Backport https://github.com/go-gitea/gitea/pull/30076.
This PR replaces the use of `max( id )`, and instead using ``max(
`index` )`` for determining the latest commit status. Building business
logic over an `auto_increment` primary key like `id` is risky and
there’re already plenty of discussions on the Internet.
There‘s no guarantee for `auto_increment` values to be monotonic,
especially upon failures or with a cluster. In the specific case, we met
the problem of commit statuses being outdated when using TiDB as the
database. As [being
documented](https://docs.pingcap.com/tidb/stable/auto-increment),
`auto_increment` values assigned to an `insert` statement will only be
monotonic on a per server (node) basis.
Closes#30074.
Backport #30061 by @wolfogre
Help #29999, or its tests cannot pass.
Also, add some comments to clarify the usage of `TxContext`.
I don't check all usages of `TxContext` because there are too many
(almost 140+). It's a better idea to replace them with `WithTx` instead
of checking them one by one. However, that may be another refactoring
PR.
Co-authored-by: Jason Song <i@wolfogre.com>
Backport #30013 by @DrMaxNix
This PR adds `setting.Service.DefaultOrgMemberVisible` value to dataset
of user when the initial org creator is being added to the created org.
Fixes#30012.
Co-authored-by: DrMaxNix <mail@drmaxnix.de>
This PR will avoid load pullrequest.Issue twice in pull request list
page. It will reduce x times database queries for those WIP pull
requests.
Partially fix#29585
Backport #29900
Fix#29763
Backport #29783
This PR fixes 2 problems with CodeOwner in the pull request.
- Don't use the pull request base branch but merge-base as a diff base
to detect the code owner.
- CodeOwner detection in fork repositories will be disabled because
almost all the fork repositories will not change CODEOWNERS files but it
should not be used on fork repositories' pull requests.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #29254
The tests on migration tests failed but CI reports successfully
https://github.com/go-gitea/gitea/actions/runs/7364373807/job/20044685969#step:8:141
This PR will fix the bug on migrations and also the CI hidden behaviour.
The reason is on the Makefile
`GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags='$(TEST_TAGS)' $(MIGRATE_TEST_PACKAGES)` will
return the error exit code.
But
`for pkg in $(shell $(GO) list
code.gitea.io/gitea/models/migrations/...); do \
GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags '$(TEST_TAGS)' $$pkg; \
done`
will not work.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Backport #29430
Thanks to inferenceus : some sort orders on the "explore/users" page
could list users by their lastlogintime/updatetime.
It leaks user's activity unintentionally. This PR makes that page only
use "supported" sort orders.
Removing the "sort orders" could also be a good solution, while IMO at
the moment keeping the "create time" and "name" orders is also fine, in
case some users would like to find a target user in the search result,
the "sort order" might help.
Backport #29531 by wxiaoguang
Add two "HTMLURL" methods for PackageDescriptor.
And rename "FullWebLink" to "VersionWebLink"
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #29525 by @wxiaoguang
* Follow #17746: `HasIssueContentHistory` should use expr builder to
make sure zero value (0) be respected.
* Add "doer" check to make sure `canSoftDeleteContentHistory` only be
called by sign-in users.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #27263 by @lunny
This PR will also keep the consistent between list assigned users and
check assigned users.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
The bug has been fixed on v1.22 but not backport to v1.21.
This original PR have many refactors so I don't think it's necessary to
backport all of them.
Fix#28667
Backport #29006 by @lunny
This reverts commit fa8c3beb26. #28546
Because it seems performance become worse.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #28817 by @lunny
Fix#22066
# Purpose
This PR fix the releases will be deleted when mirror repository sync the
tags.
# The problem
In the previous implementation of #19125. All releases record in
databases of one mirror repository will be deleted before sync.
Ref:
https://github.com/go-gitea/gitea/pull/19125/files#diff-2aa04998a791c30e5a02b49a97c07fcd93d50e8b31640ce2ddb1afeebf605d02R481
# The Pros
This PR introduced a new method which will load all releases from
databases and all tags on git data into memory. And detect which tags
needs to be inserted, which tags need to be updated or deleted. Only
tags releases(IsTag=true) which are not included in git data will be
deleted, only tags which sha1 changed will be updated. So it will not
delete any real releases include drafts.
# The Cons
The drawback is the memory usage will be higher than before if there are
many tags on this repository. This PR defined a special release struct
to reduce columns loaded from database to memory.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport https://github.com/go-gitea/gitea/pull/28794Fixes#22236
---
Error occurring currently while trying to revert commit using read-tree
-m approach:
> 2022/12/26 16:04:43 ...rvices/pull/patch.go:240:AttemptThreeWayMerge()
[E] [63a9c61a] Unable to run read-tree -m! Error: exit status 128 -
fatal: this operation must be run in a work tree
> - fatal: this operation must be run in a work tree
We need to clone a non-bare repository for `git read-tree -m` to work.
bb371aee6e
adds support to create a non-bare cloned temporary upload repository.
After cloning a non-bare temporary upload repository, we [set default
index](https://github.com/go-gitea/gitea/blob/main/services/repository/files/cherry_pick.go#L37)
(`git read-tree HEAD`).
This operation ends up resetting the git index file (see investigation
details below), due to which, we need to call `git update-index
--refresh` afterward.
Here's the diff of the index file before and after we execute
SetDefaultIndex: https://www.diffchecker.com/hyOP3eJy/
Notice the **ctime**, **mtime** are set to 0 after SetDefaultIndex.
You can reproduce the same behavior using these steps:
```bash
$ git clone https://try.gitea.io/me-heer/test.git -s -b main
$ cd test
$ git read-tree HEAD
$ git read-tree -m 1f085d7ed8 1f085d7ed8 9933caed00
error: Entry '1' not uptodate. Cannot merge.
```
After which, we can fix like this:
```bash
$ git update-index --refresh
$ git read-tree -m 1f085d7ed8 1f085d7ed8 9933caed00
```
Backport #26745Fixes#26548
This PR refactors the rendering of markup links. The old code uses
`strings.Replace` to change some urls while the new code uses more
context to decide which link should be generated.
The added tests should ensure the same output for the old and new
behaviour (besides the bug).
We may need to refactor the rendering a bit more to make it clear how
the different helper methods render the input string. There are lots of
options (resolve links / images / mentions / git hashes / emojis / ...)
but you don't really know what helper uses which options. For example,
we currently support images in the user description which should not be
allowed I think:
<details>
<summary>Profile</summary>
https://try.gitea.io/KN4CK3R
</details>
Fix#28157
Backport #28691
This PR fix the possible bugs about actions schedule.
- Move `UpdateRepositoryUnit` and `SetRepoDefaultBranch` from models to
service layer
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when actions unit has been disabled
or global disabled.
- Remove schedules plan from database and cancel waiting & running
schedules tasks in this repository when default branch changed.
Backport #28590 by @lunny
Fix https://github.com/go-gitea/gitea/pull/28547#issuecomment-1867740842
Since https://gitea.com/xorm/xorm/pulls/2383 merged, xorm now supports
UPDATE JOIN.
To keep consistent from different databases, xorm use
`engine.Join().Update`, but the actural generated SQL are different
between different databases.
For MySQL, it's `UPDATE talbe1 JOIN table2 ON join_conditions SET xxx
Where xxx`.
For MSSQL, it's `UPDATE table1 SET xxx FROM TABLE1, TABLE2 WHERE
join_conditions`.
For SQLITE per https://www.sqlite.org/lang_update.html, sqlite support
`UPDATE table1 SET xxx FROM table2 WHERE join conditions` from
3.33.0(2020-8-14).
POSTGRES is the same as SQLITE.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #28593 by @lunny
This reverts commit b35d3fddfa.
This is totally wrong. I think `Update join` hasn't been supported well
by xorm.
I just revert the PR and will try to send another one.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #28552 by @6543
can we please PLEAS PLEASE only use raw SQL statements if it is relay
needed!!!
source is https://github.com/go-gitea/gitea/pull/28544 (before
refactoring)
Co-authored-by: 6543 <m.huber@kithara.com>
Backport #28392 by @nekrondev
Windows-based shells will add a CRLF when piping the token into
ssh-keygen command resulting in
verification error. This resolves#21527.
Co-authored-by: nekrondev <heiko@noordsee.de>
Co-authored-by: Heiko Besemann <heiko.besemann@qbeyond.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Fix#28056
Backport #28361
This PR will check whether the repo has zero branch when pushing a
branch. If that, it means this repository hasn't been synced.
The reason caused that is after user upgrade from v1.20 -> v1.21, he
just push branches without visit the repository user interface. Because
all repositories routers will check whether a branches sync is necessary
but push has not such check.
For every repository, it has two states, synced or not synced. If there
is zero branch for a repository, then it will be assumed as non-sync
state. Otherwise, it's synced state. So if we think it's synced, we just
need to update branch/insert new branch. Otherwise do a full sync. So
that, for every push, there will be almost no extra load added. It's
high performance than yours.
For the implementation, we in fact will try to update the branch first,
if updated success with affect records > 0, then all are done. Because
that means the branch has been in the database. If no record is
affected, that means the branch does not exist in database. So there are
two possibilities. One is this is a new branch, then we just need to
insert the record. Another is the branches haven't been synced, then we
need to sync all the branches into database.
Backport #28243
Setting the same value should not trigger DuplicateKey error, and the
"version" should be increased
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Backport #28072
To avoid unnecessary database access, the `cacheTime` should always be
set if the revision has been checked.
Fix#28057
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
