This is a squashed result of conflict resolution for the following commits from Gitea:
- 36de5b299b
- 9a93b1816e
- 712e19fa6f
- 83850cc479
It is lacking CSS rule for archived labels, though.
Changes in this commit are authored by:
- 6543
- delvh
- silverwind
(cherry picked from commit 4b09dd11ec)
Instead of db.TruncateBeans(db.DefaultContext, &issues_model.Review{}), reviews are deleted using issue.DeleteReview
(cherry picked from commit 6b857193ff)
- Use the correct template that was given when there's an error in
retrieving which git identity should be used.
- Remove the error from the exception list.
- 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
This makes signed tags show a badge in the tag list similar to signed
commits in the commit list, and a more verbose block when viewing a
single tag. Works for both GPG and SSH signed tags.
Fixes#1316.
Work sponsored by @glts.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
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)
On creation of an empty project (no template) a default board will be
created instead of falling back to the uneditable pseudo-board.
Every project now has to have exactly one default boards. As a
consequence, you cannot unset a board as default, instead you have to
set another board as default. Existing projects will be modified using a
cron job, additionally this check will run every midnight by default.
Deleting the default board is not allowed, you have to set another board
as default to do it.
Fixes#29873Fixes#14679 along the way
Fixes#29853
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit e5160185ed65fd1c2bcb2fc7dc7e0b5514ddb299)
Conflicts:
options/locale/locale_en-US.ini
trivial conflict because Forgejo strings do not have
surrounding double quotes
Now, the chars `=:;()[]{}~!@#$%^ &` are possible as well
Fixes#30134
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 1ad48f781eb0681561b083b49dfeff84ba51f2fe)
(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
Regression of #29493. If a branch has been deleted, repushing it won't
restore it.
Lunny may have noticed that, but I didn't delve into the comment then
overlooked it:
https://github.com/go-gitea/gitea/pull/29493#discussion_r1509046867
The additional comments added are to explain the issue I found during
testing, which are unrelated to the fixes.
(cherry picked from commit f371f84fa3456c2a71470632b6458d81e4892a54)
The error message:
`editor.file_changed_while_editing = The file contents have changed
since you started editing. <a target="_blank" rel="noopener noreferrer"
href="%s">Click here</a> to see them or <strong>Commit Changes
again</strong> to overwrite them.`
Is re-used in inappropriate contexts. The link in the key goes to a 404
when the key is used in a situation where the file contents have not
changed.
Added two new keys to differentiate commit id mismatch and push out of
date conditions.
(cherry picked from commit 16e360099d0a515d429538ec88cff1f3ede23fb4)
- If a branch cannot be renamed due to a protected branch rule, show
this error in the UI instead of throwing an internal server error.
- Add integration test (also simplify the existing one).
- Resolves#2751
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>
shields.io uses dashes to separate parts of the badge it needs to
return. If our label or text parts contain dashes, we need to encode
those for shields.io to recognise what we want it to do, and to have the
correct text on the badge, too.
Fortunately, this is as simple as replacing all dashes with double
dashes in both the label and the text parts. We do not need to do the
same for the color, because that part is not user controlled.
This fixes the badges for cases when a workflow name includes dashes, or
when a release's tag name does.
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
Fix#20175
Current implementation of API does not allow creating pull requests
between branches of the same
repo when you specify *namespace* (owner of the repo) in `head` field in
http request body.
---
Although GitHub implementation of API allows performing such action and
since Gitea targeting
compatibility with GitHub API I see it as an appropriate change.
I'm proposing a fix to the described problem and test case which covers
this logic.
My use-case just in case:
https://github.com/go-gitea/gitea/issues/20175#issuecomment-1711283022
(cherry picked from commit ed02d1fab85c9b8206c0af84dcfc3792e61609cf)
This PR do some loading speed optimization for feeds user interface
pages.
- Load action users batchly but not one by one.
- Load action repositories batchly but not one by one.
- Load action's Repo Owners batchly but not one by one.
- Load action's possible issues batchly but not one by one.
- Load action's possible comments batchly but not one by one.
(cherry picked from commit aed3b53abdd02a3ffbf9e8eb90272ff567333073)
It's unnecessary to detect the repository object format from git
repository. Just use the repository's object format name.
(cherry picked from commit 3c6fc25a77c37d50686caa495d27a31dcef7f75f)
Conflicts:
services/pull/pull.go
Add the same auth check and middlewares as the /v1/ API.
It require to export some variable from /v1 API, i am not sure if is the correct way to do
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2582
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Ada <ada@gnous.eu>
Co-committed-by: Ada <ada@gnous.eu>
Unlike other async processing in the queue, we should sync branches to
the DB immediately when handling git hook calling. If it fails, users
can see the error message in the output of the git command.
It can avoid potential inconsistency issues, and help #29494.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
The `reloadParam` function already calls `context.UserAssignmentWeb`
with the same parameters, there's no need to do it again.
Change cherry picked from gitea#29751.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
meilisearch does not have an search option to contorl fuzzynes per query
right now:
- https://github.com/meilisearch/meilisearch/issues/1192
- https://github.com/orgs/meilisearch/discussions/377
- https://github.com/meilisearch/meilisearch/discussions/1096
so we have to create a workaround by post-filter the search result in
gitea until this is addressed.
For future works I added an option in backend only atm, to enable
fuzzynes for issue indexer too.
And also refactored the code so the fuzzy option is equal in logic to
code indexer
---
*Sponsored by Kithara Software GmbH*
Conflicts:
routers/web/repo/search.go
trivial context confict s/isMatch/isFuzzy/
(cherry picked from commit 25b842df261452a29570ba89ffc3a4842d73f68c)
Conflicts:
routers/web/repo/wiki.go
services/repository/branch.go
services/repository/migrate.go
services/wiki/wiki.go
also apply to Forgejo specific usage of the refactored functions
After repository commit status has been introduced on dashaboard, the
most top SQL comes from `GetLatestCommitStatusForPairs`.
This PR adds a cache for the repository's default branch's latest
combined commit status. When a new commit status updated, the cache will
be marked as invalid.
<img width="998" alt="image"
src="https://github.com/go-gitea/gitea/assets/81045/76759de7-3a83-4d54-8571-278f5422aed3">
(cherry picked from commit e308d25f1b2fe24b4735432b05e5e221879a2705)
Detect broken git hooks by checking if the commit id of branches in DB
is the same with the git repo.
It can help #29338#28277 and maybe more issues.
Users could complain about actions, webhooks, and activities not
working, but they were not aware that it is caused by broken git hooks
unless they could see a warning.
<img width="1348" alt="image"
src="https://github.com/go-gitea/gitea/assets/9418365/2b92a46d-7f1d-4115-bef4-9f970bd695da">
It should be merged after #29493. Otherwise, users could see a ephemeral
warning after committing and opening the repo home page immediately.
And it also waits for #29495, since the doc link (the anchor part) will
be updated.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit a4bcfb8ef1d5b2b522f78c9560d53ddbdbb02218)
Follow #29522
Administrators should be able to set a user's email address even if the
email address is not in `EMAIL_DOMAIN_ALLOWLIST`
(cherry picked from commit 136dd99e86eea9c8bfe61b972a12b395655171e8)
