Fix#30378
(cherry picked from commit 0fe9f93eb4c94d55e43b18b9c3cc6d513a34c0b5)
Conflicts:
- models/organization/org.go
- services/repository/delete.go
- services/user/delete.go
In all three cases, conflicts were resolved by manually adding
the lines added by the Gitea patch, keeping the Forgejo code
surrounding them.
- `RemoveFilesFromIndex` used an hardcoded empty commit ID for the SHA1
object format, this would result in an error if the repository was
initialized to use the sha256 object format. Get the object format of
the Git repository and use that to get the empty commit id.
- Adds unit test.
- Resolves#3184
(cherry picked from commit eeaef556c2)
Backport #30392 by @jam7
This patch improves the migration from gitbucket to gitea.
The gitbucket uses it's own internal perPage value (= 25) for paging and
ignore per_page arguments in the requested URL. This cause gitea to
migrate only 25 issues and 25 PRs from gitbucket repository. This may
not happens on old gitbucket. But recent gitbucket 4.40 or 4.38.4 has
this problem.
This patch change to use this internally hardcoded perPage of gitbucket
as gitea's maxPerPage numer when migrating from gitbucket. There are
several perPage values in gitbucket like 25 for Isseus/PRs and 10 for
Releases. Some of those API doesn't support paging yet. It sounds
difficult to implement, but using the minimum number among them worked
out very well. So, I use 10 in this patch.
Brief descriptions of problems and this patch are also available in
https://github.com/go-gitea/gitea/issues/30316.
In addition, I'm not sure what kind of test cases are possible to write
here. It's a test for migration, so it requires testing gitbucket server
and gitea server, I guess. Please let me know if it is possible to write
such test cases here. Thanks!
Co-authored-by: Kazushi (Jam) Marukawa <jam@pobox.com>
(cherry picked from commit b941d7485b53e5dd093a1cce3c9ff47c91d4fc58)
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>
(cherry picked from commit 69cc79173ddbf7662c4d7246b6161b9351038d16)
`log.Xxx("%v")` is not ideal, this PR adds necessary context messages.
Remove some unnecessary logs.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 83f83019ef3471b847a300f0821499b3896ec987)
Conflicts:
- modules/util/util.go
Conflict resolved by picking `util.Iif` from 654cfd1dfbd3f3f1d94addee50b6fe2b018a49c3
(cherry picked from commit 492d116b2a468991f44d6d37ec33f918ccbe4514)
Conflicts:
modules/util/util.go
trivial context conflict as the commit is picked from https://codeberg.org/forgejo/forgejo/pulls/3212
The user that caused the notification to re-evaluates the
schedules is not the one that will trigger the workflows. They are
background tasks that are authored by the action user (id -2).
Such a mis-assignment is problematic when the user that caused the
notification is deleted.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3211
(cherry picked from commit c3e2c25359)
* Split TestPullRequest out of AddTestPullRequestTask
* A Created field is added to the Issue table
* The Created field is set to the time (with nano resolution) on creation
* Record the nano time repo_module.PushUpdateOptions is created by the hook
* The decision to update a pull request created before a commit was
pushed is based on the time (with nano resolution) the git hook
was run and the Created field
It ensures the following happens:
* commit C is pushed
* the git hook queues AddTestPullRequestTask for processing and returns with success
* TestPullRequest is not called yet
* a pull request P with commit C as the head is created
* TestPullRequest runs and ignores P because it was created after the commit was received
When the "created" column is NULL, no verification is done, pull
requests that were created before the column was created in the
database cannot be newer than the latest call to a git hook.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2009
(cherry picked from commit 998a431747)
Conflicts:
models/forgejo_migrations/migrate.go
see https://codeberg.org/forgejo/forgejo/pulls/3165#issuecomment-1755941
services/pull/pull.go
trivial conflicts
- The code that gets contributor stats tried to store an
`map[string]*ContributorData` type in the cache, this works for the
memory cache but not for other caches such as Redis.
- The cache implementation for Redis would convert this map via
`fmt.Sprintf` to an string, which would simply print the pointer and not
the value of the pointer. Storing pointers is a no-go as this will get
GC-ed eventually within a few minutes. Therefore store everything with
json, that does properly store the value of the pointers.
- Adds unit test that verifies JSON is being used.
- Resolves https://codeberg.org/forgejo/forgejo/issues/3158
(cherry picked from commit 4c8b67c4b2)
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/1518
An attempt at adding an optional pronoun field for user profiles, as suggested here 3 years ago: https://github.com/go-gitea/gitea/issues/13990
I made this for [my own instance](https://git.gay/h) and didn't initially think I'd make a PR because of the previous closed issue, but I thought I'd ask the Forgejo matrix chat to see if there was any support and there was!
I'm told I should make a database migration, some help as to how to do that would be appreciated.
Co-authored-by: hazycora <hazysu@riseup.net>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3076
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
- Remove options that currently aren't set
on `GarbageCollectLFSMetaObjectsOptions` and
`IterateLFSMetaObjectsForRepoOptions`.
- Simplify `IterateRepositoryIDsWithLFSMetaObjects` and
`IterateLFSMetaObjectsForRepo`.
- `IterateLFSMetaObjectsForRepo` was previously able to get in a
loop (`gc-lfs` doctor check was able to reproduce this) because the code
expected that the records would be updated to not match the SQL query,
but that wasn't the case. Simply enforce that only records higher than
the latest `id` from the previous iteration are allowed.
- For `gc-lfs` doctor check this was because `UpdatedLessRecentlyThan`
option was not set, which caused that records just marked as active in
the iteration weren't being filtered.
- Add unit tests
- Most likely a regression from 2cc3a6381c.
- The bug with `gc-lfs` was found on Codeberg.
(cherry picked from commit 7ffa7f5bce)
- When the database consistency is being run it would check for any
OAuth2 applications that don't have an existing user. However there are
few special OAuth2 applications that don't have an user set, because
they are global applications.
- This was not taken into account by the database consistency checker
and were removed if the database consistency check was being run with
autofix enabled.
- Take into account to ignore these global OAuth2 applications when
running the database consistency check.
- Add unit tests.
- Ref: https://codeberg.org/Codeberg/Community/issues/1530
(cherry picked from commit 6af8f3a3f2)
- Currently protected branch rules do not apply to admins, however in
some cases (like in the case of Forgejo project) you might also want to
apply these rules to admins to avoid accidental merges.
- Add new option to configure this on a per-rule basis.
- Adds integration tests.
- Resolves#65
Resolves#29965.
---
Manually tested this by:
- Following the
[installation](https://docs.gitea.com/next/installation/install-with-docker#basics)
guide (but built a local Docker image instead)
- Creating 2 users, one who is the `Owner` of a newly-created repository
and the other a `Collaborator`
- Had the `Collaborator` create a PR that the `Owner` reviews
- `Collaborator` resolves conversation and `Owner` merges PR
And with this change we see that we can no longer see re-request review
button for the `Owner`:
<img width="1351" alt="Screenshot 2024-03-25 at 12 39 18 AM"
src="https://github.com/go-gitea/gitea/assets/60799661/bcd9c579-3cf7-474f-a51e-b436fe1a39a4">
(cherry picked from commit 242b331260925e604150346e61329097d5731e77)
- Remove `gitea.com/lunny/dingtalk_webhook` as dependency, we only use
two structs which are small enough to be recreated in Forgejo and don't
need to rely on the dependency.
- Existing tests (thanks @oliverpool) prove that this has no effect.
- `user_model.DeleteInactiveEmailAddresses` related code was added in
Gogs as part to delete inactive users, however since then the related
code to delete users has changed and this code now already delete email
addresses of the user, it's therefore not needed anymore to
`DeleteInactiveEmailAddresses`.
- The call to `DeleteInactiveEmailAddresses` can actually cause issues.
As the associated user might not have been deleted, because it
was not older than the specified `olderThan` argument. Therefore causing
a database inconsistency and lead to internal server errors if the user
tries to activate their account.
- Adds unit test to verify correct behavior (fails without this patch).
Fixes https://github.com/go-gitea/gitea/issues/28297
This PR also fixed a problem that it needs a database transaction when
removing the WIP title.
---
Resolves#2771
Also partially ports gitea#29783
(cherry picked from commit 17d7ab5ad4ce3d0fbc1251572c22687c237a30b1)
The fix against the race incorrectly assumes the sha of the commit being
pushed belongs to the base repository. It finds the highest possible
pull request ID from the head repository instead of looking it up in
the base repository.
Figuring out if a PR was created in the future based on the highest
index of the base repository would require collecting all of them
because there is no way to know in advance which repository may be
involved in the race.
Fixing this race can be done either by:
* Introducing a new field in the pull_request table https://codeberg.org/forgejo/forgejo/pulls/2842
which feels more like a hack than a real solution
* Refactoring the logic
which would be a significant undertaking
The race has been in the codebase for a very long time and manifests
itself in the CI, when events happen in quick succession. The only
concrete manifestation was however fixed by https://codeberg.org/forgejo/forgejo/issues/2009
Since this race now only exists in theory and not in practice, let's
revert this bugous commit until a proper solution is implemented.
Fixes: https://codeberg.org/forgejo/forgejo/issues/2817
This reverts commit 036f1eddc5.
Conflicts:
services/pull/pull.go
(cherry picked from commit f8ab9dafb7a173a35e9308f8f784735b0f822439)
Conflicts:
routers/web/repo/fork.go
trivial context conflict, the file does not exist in Forgejo
Fix#28761Fix#27884Fix#28093
## Changes
### Rerun all jobs
When rerun all jobs, status of the jobs with `needs` will be set to
`blocked` instead of `waiting`. Therefore, these jobs will not run until
the required jobs are completed.
### Rerun a single job
When a single job is rerun, its dependents should also be rerun, just
like GitHub does
(https://github.com/go-gitea/gitea/issues/28761#issuecomment-2008620820).
In this case, only the specified job will be set to `waiting`, its
dependents will be set to `blocked` to wait the job.
### Show warning if every job has `needs`
If every job in a workflow has `needs`, all jobs will be blocked and no
job can be run. So I add a warning message.
<img
src="https://github.com/go-gitea/gitea/assets/15528715/88f43511-2360-465d-be96-ee92b57ff67b"
width="480px" />
(cherry picked from commit 2f060c5834d81f0317c795fc281f9a07e03e5962)
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
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 62f8174aa2fae1481c7e17a6afcb731a5b178cd0)
Conflicts:
models/activities/notification_list.go
moved to models/activities/notification.go
This PR fixed a bug when the user switching pages too fast, he will
logout automatically.
The reason is that when the error is context cancelled, the previous
code think user hasn't login then the session will be deleted. Now it
will return the errors but not think it's not login.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 82db9a2ba77d2a6c470b62be3c82b73c0a544fcc)
Fix#29731
Caused by #24634
Also remove fixme.
ps: we can not fix the existed runs, as wrong refs are all recorded in
DB, and we can not know whether they are branch or tag:
(cherry picked from commit 98217b034076157547cf688cc10f47cd3275c872)
Conflicts:
tests/integration/actions_trigger_test.go
there is a need for more imports because the exist tests
are done differently, using CreateDeclarativeRepo
Fix#29040
`handleSchedules` should be called only if `DetectWorkflows` should
detect schedule workflows
(cherry picked from commit e600c35f066c79b717dc0c416b07d5c34502d286)
In #28691, schedule plans will be deleted when a repo's actions unit is
disabled. But when the unit is enabled, the schedule plans won't be
created again.
This PR fixes the bug. The schedule plans will be created again when the
actions unit is re-enabled
(cherry picked from commit adc3598a75)
Fix#28157
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.
(cherry picked from commit 97292da960)
Conflicts:
modules/actions/github.go
routers/web/repo/setting/default_branch.go
routers/web/repo/setting/setting.go
services/repository/branch.go
services/repository/setting.go
tests/integration/actions_trigger_test.go
Repositories displaying an "Add more..." tab on the header is a neat way
to let people discover they can enable more units. However, displaying
it all the time for repository owners, even when they deliberately do
not want to enable more units gets noisy very fast.
As such, this patch introduces a new setting which lets people disable
this hint under the appearance settings.
Fixes#2378.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Currently in the Cargo section of the packages setting menu two
buttons are always shown, "Initalize index" and "Rebuild index", however
only of these should be shown depending on the state of the index, if
there's no index the "Initalize index" button should be shown and if
there's an index the "Rebuild index" button should be shown. This patch
does exactly that.
- Resolves#2628
Zettat123