- Currently the parsing of the push options require that `=` is present
in the value, however we shouldn't be that strict and assume if that's
not set the value is `true`.
- This allow for more natural commands, so become `-o force-push=true`
simply `-o force-push`.
- Add unit test.
Now, the chars `=:;()[]{}~!@#$%^ &` are possible as well
Fixes#30134
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 1ad48f781eb0681561b083b49dfeff84ba51f2fe)
- 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
Fixes: https://github.com/go-gitea/gitea/issues/29981. Introduce
`.secondary-nav` as a universal way for styling and margin adjustments
inside `.page-content`.
If the first child of `.page-content` is `.secondary-nav`, we add margin
below it, otherwise we add padding to the first child. Notable changes:
- `--color-header-wrapper` is replaced with `--color-secondary-nav-bg`.
- `navbar` class is removed.
Co-authored-by: Giteabot <teabot@gitea.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
---
Conflict resolution: Trivial conflict & changed selector to reflect new
classes.
Ref: https://codeberg.org/forgejo/forgejo/issues/2776
(cherry picked from commit 3ccda41a539b8ba7841919ee12dc2877ddc03818)
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
- Currently it's possible to modify remote references such as
`refs/pull/<idx>/head` and `refs/heads/<branch>`.
- Disallow that the pull request reference is deleted, as this should
not be at the control of the user. Doing so would result in
inconsistencies within Forgejo and lead to internal server errors when
trying access the pull request, this action should be reserved for
Forgejo.
- Do this by utilizing the `update` hook, which process each reference
individually and therefore allow to only skip deleting internal
references and still allow other modifications that is being done in
the same push.
- Ref: https://codeberg.org/Codeberg/Community/issues/1517
also bleve did match on fuzzy search and the other way around. this also fix that bug.
(cherry picked from commit b9c57fb78e8e0d80d786d8e1da433b6c7ebf2f1c)
Conflicts:
tests/integration/repo_search_test.go
simple conflict resolution in the tests
Fixes https://github.com/go-gitea/gitea/issues/30005. Regression from
https://github.com/go-gitea/gitea/pull/29945.
There was only once instance of `tw-content-center` before that PR, so I
just ran below command and reverted that one instance.
```sh
perl -p -i -e 's#tw-content-center#tw-items-center#g' web_src/js/**/* templates/**/* models/**/* tests/**/*
```
(cherry picked from commit 04f9ad056882fc3f21b247b16f84437adf0f36d8)
Conflicts:
templates/repo/diff/conversation.tmpl
templates/repo/header.tmpl
templates/repo/issue/filter_list.tmpl
templates/repo/issue/view_content/conversation.tmpl
templates/repo/wiki/view.tmpl
web_src/js/components/DashboardRepoList.vue
re-ran the command after discarding the Gitea changes to
ensure all Forgejo files are also covered
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
5143ebb507 Add rel="nofollow" to issue filter links
has a test that fails because it assumes the link starts with the link
where it now starts with a ?
In HTML, `?key=val` already means "use the current link with new query parameters"
(cherry picked from commit 4c476fa41dc29dc24afda0925023ae3d0b9707cd)
Conflicts:
templates/repo/issue/filter_list.tmpl
templates/shared/issuelist.tmpl
trivial context conflict because the lines in Forgejo have rel=nofollow
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)
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
- 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
The alert/callout blocks rendering has been changed in the previous few
commits, this adapts the test case that verifies them to the updated
output.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
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)
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>
This should be a failing test for Firefox (but working in Chrome?) for
the taborder in the explore page.
Tabbing through the page should ensure that certain elements are focused
at least once.
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)
Fix#27457
Administrators should be able to manually create any user even if the
user's email address is not in `EMAIL_DOMAIN_ALLOWLIST`.
(cherry picked from commit 4fd9c56ed09b31e2f6164a5f534a31c6624d0478)
Fixes#28853
Needs both https://gitea.com/gitea/act_runner/pulls/473 and
https://gitea.com/gitea/act_runner/pulls/471 on the runner side and
patched `actions/upload-artifact@v4` / `actions/download-artifact@v4`,
like `christopherhx/gitea-upload-artifact@v4` and
`christopherhx/gitea-download-artifact@v4`, to not return errors due to
GHES not beeing supported yet.
(cherry picked from commit a53d268aca87a281aadc2246541f8749eddcebed)
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.
(cherry picked from commit eedb8f41297c343d6073a7bab46e4df6ee297a90)
Since `modules/context` has to depend on `models` and many other
packages, it should be moved from `modules/context` to
`services/context` according to design principles. There is no logic
code change on this PR, only move packages.
- Move `code.gitea.io/gitea/modules/context` to
`code.gitea.io/gitea/services/context`
- Move `code.gitea.io/gitea/modules/contexttest` to
`code.gitea.io/gitea/services/contexttest` because of depending on
context
- Move `code.gitea.io/gitea/modules/upload` to
`code.gitea.io/gitea/services/context/upload` because of depending on
context
(cherry picked from commit 29f149bd9f517225a3c9f1ca3fb0a7b5325af696)
Conflicts:
routers/api/packages/alpine/alpine.go
routers/api/v1/repo/issue_reaction.go
routers/install/install.go
routers/web/admin/config.go
routers/web/passkey.go
routers/web/repo/search.go
routers/web/repo/setting/default_branch.go
routers/web/user/home.go
routers/web/user/profile.go
tests/integration/editor_test.go
tests/integration/integration_test.go
tests/integration/mirror_push_test.go
trivial context conflicts
also modified all other occurrences in Forgejo specific files
This partially reverts c41b2c73ef21d5c54c7f2658ceffaa163b135131: for the
sake of consistency, the title of a release should always be a link,
whether it's a tag-only release or not.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Update the `TestTagViewWithoutRelease` test case with another assert:
one that checks that the release title is properly displayed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
