When in the repository settings, visiting
- `LFS` to `/{owner}/{repo}/settings/lfs`
- `Find pointer files` to `/{owner}/{repo}/settings/lfs/pointers`
- `Find commits` to `/{owner}/{repo}/settings/lfs/find?oid=...`
failed with an error 500 because of an incorrect evaluation of the
template.
Regression introduced by
cbf923e87b
A test is added to visit the page and guard against future
regressions.
Refs: https://codeberg.org/forgejo/forgejo/issues/3438
A remote user (UserTypeRemoteUser) is a placeholder that can be
promoted to a regular user (UserTypeIndividual). It represents users
that exist somewhere else. Although the UserTypeRemoteUser already
exists in Forgejo, it is neither used or documented.
A new login type / source (Remote) is introduced and set to be the login type
of remote users.
Type UserTypeRemoteUser
LogingType Remote
The association between a remote user and its counterpart in another
environment (for instance another forge) is via the OAuth2 login
source:
LoginName set to the unique identifier relative to the login source
LoginSource set to the identifier of the remote source
For instance when migrating from GitLab.com, a user can be created as
if it was authenticated using GitLab.com as an OAuth2 authentication
source.
When a user authenticates to Forejo from the same authentication
source and the identifier match, the remote user is promoted to a
regular user. For instance if 43 is the ID of the GitLab.com OAuth2
login source, 88 is the ID of the Remote loging source, and 48323
is the identifier of the foo user:
Type UserTypeRemoteUser
LogingType Remote
LoginName 48323
LoginSource 88
Email (empty)
Name foo
Will be promoted to the following when the user foo authenticates to
the Forgejo instance using GitLab.com as an OAuth2 provider. All users
with a LoginType of Remote and a LoginName of 48323 are examined. If
the LoginSource has a provider name that matches the provider name of
GitLab.com (usually just "gitlab"), it is a match and can be promoted.
The email is obtained via the OAuth2 provider and the user set to:
Type UserTypeIndividual
LogingType OAuth2
LoginName 48323
LoginSource 43
Email foo@example.com
Name foo
Note: the Remote login source is an indirection to the actual login
source, i.e. the provider string my be set to a login source that does
not exist yet.
Add a new member to `DeclarativeRepoOptions`: `WikiBranch`. If
specified, create a Wiki with the given branch, and a single "Home"
page.
This will be used by an upcoming test.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Lets introduce a new helper function,
`CreateDeclarativeRepoWithOptions`! This is almost the same as the
existing `CreateDeclarativeRepo` helper, but instead of taking a list of
random parameters the author thought of at the time of its introduction,
it takes a `DeclarativeRepoOptions` struct, with optional members.
This makes it easier to extend the function, as new members can be added
without breaking or having to update existing callsites, as long as the
newly added members default to compatible values.
`CreateDeclarativeRepo` is then reimplemented on top of the new
function. Callsites aren't updated yet, we can do that organically,
whenever touching code that uses the older function.
No new functionality is introduced just yet, this is merely a refactor.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This adds a new options to releases to hide the links to the automatically generated archives. This is useful, when the automatically generated Archives are broken e.g. because of Submodules.
Note:
This juts hides the Archives from the UI. Users can still download 5the Archive if they know t correct URL.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3139
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: 0ko <0ko@noreply.codeberg.org>
Co-authored-by: JakobDev <jakobdev@gmx.de>
Co-committed-by: JakobDev <jakobdev@gmx.de>
When searching for users, page the results by default, and respect the
default paging limits.
This makes queries like '/api/v1/users/search?limit=1' actually work.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Fixes: https://github.com/go-gitea/gitea/issues/30512
I think this does mean those tools would run on a potential `vendor`
directory, but I'm not sure we really support vendoring of dependencies
anymore.
`release` has a `vendor` prerequisite so likely the source tarballs
contain vendor files?
(cherry picked from commit 8e12ef911a1d10dedb03e3127c42ca76f9850aca)
Conflicts:
- Makefile
Manually adjusted the changes.
- Add new `Compare` struct to represent comparison between two commits
- Introduce new API endpoint `/compare/*` to get commit comparison
information
- Create new file `repo_compare.go` with the `Compare` struct definition
- Add new file `compare.go` in `routers/api/v1/repo` to handle
comparison logic
- Add new file `compare.go` in `routers/common` to define `CompareInfo`
struct
- Refactor `ParseCompareInfo` function to use `common.CompareInfo`
struct
- Update Swagger documentation to include the new API endpoint for
commit comparison
- Remove duplicate `CompareInfo` struct from
`routers/web/repo/compare.go`
- Adjust base path in Swagger template to be relative (`/api/v1`)
GitHub API
https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#compare-two-commits
---------
Signed-off-by: Bo-Yi Wu <appleboy.tw@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit c70e442ce4b99e2a1f1bf216afcfa1ad78d1925a)
Conflicts:
- routers/api/v1/swagger/repo.go
Conflict resolved by manually adding the lines from the Gitea
PR.
It is possible to change some repo settings (its visibility, and
template status) via `git push` options: `-o repo.private=true`, `-o
repo.template=true`.
Previously, there weren't sufficient permission checks on these, and
anyone who could `git push` to a repository - including via an AGit
workflow! - was able to change either of these settings. To guard
against this, the pre-receive hook will now check if either of these
options are present, and if so, will perform additional permission
checks to ensure that these can only be set by a repository owner or
an administrator. Additionally, changing these settings is disabled for
forks, even for the fork's owner.
There's still a case where the owner of a repository can change the
visibility of it, and it will not propagate to forks (it propagates to
forks when changing the visibility via the API), but that's an
inconsistency, not a security issue.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Signed-off-by: Earl Warren <contact@earl-warren.org>
When editing a user via the API, do not require setting `login_name` or
`source_id`: for local accounts, these do not matter. However, when
editing a non-local account, require *both*, as before.
Fixes#1861.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This is a continuation of #2728, with a test case added.
Fixes#2633.
I kept @zareck 's commit as is, because I believe it is correct. We can't move the check to `owner.CanForkRepo()`, because `owner` is the future owner of the forked repo, and may be an organization. We need to check the admin permission of the `doer`, like in the case of repository creation.
I verified that the test fails without the `ForkRepository` change, and passes with it.
Co-authored-by: Cassio Zareck <cassiomilczareck@gmail.com>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3277
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Co-committed-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The global wiki editability can be set via the web UI, this patch makes
it possible to set the same thing via the API too. This is accomplished
by adjusting the GET and PATCH handlers of the
`/api/v1/repos/{owner}/{repo}` route.
The first will include the property when checking the repo's settings,
the second allows a repo admin to change the setting too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Previously translations were escaped, but now translations are
accepted as-is and will be rendered as HTML. Use `TrString` to escape
the translation value.
- Adds integration test.
- Regression of 65248945c9.
- Resolves#3260
This PR adds a new table named commit status summary to reduce queries
from the commit status table. After this change, commit status summary
table will be used for the final result, commit status table will be for
details.
---------
Co-authored-by: Jason Song <i@wolfogre.com>
Fix https://github.com/go-gitea/gitea/issues/30428
---
Conflict resolution: trivial and move test to own subtest run directly
after `Normal`.
(cherrypicked commit 9466fec879f4f2c88c7c1e7a5cffba319282ab66)
When visiting a repos `/settings/units` page, highlight the active tab
properly: "Add more..." if the tab is displayed, or "Settings"
otherwise.
Fixes#3188.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
* 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
- Fix a crash in the issue forms, because `ctx.Ctx` was trying to be
accessed, however this is not set in all contexts thus could result to NPE.
- Adds integration test.
- Resolves#3011
- 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/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>
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 c41b2c73ef: 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>
- When a user goes opens a symlink file in Forgejo, the file would be
rendered with the path of the symlink as content.
- Add a button that is shown when the user opens a *valid* symlink file,
which means that the symlink must have an valid path to an existent
file and after 999 follows isn't a symlink anymore.
- Return the relative path from the `FollowLink` functions, because Git
really doesn't want to tell where an file is located based on the blob ID.
- Adds integration tests.
- Disable the CODEOWNERS feature for forked repositories, as it would
otherwise inadvertently request reviewers when for example a pull
request is opened against a forked repository to propose changes to an
existant pull request in the original repository.
- Adds integration test.
- Resolves#2525
- Implement the commit mail selection feature for the other supported
Git operations that can be done trough the web UI.
- Adds integration tests (goodluck reviewing this).
- Ref: #1788
Co-authored-by: 0ko <0ko@noreply.codeberg.org>
- The CODEOWNER feature relies on the changed files to determine which
reviewers should be added according to the `CODEOWNER` file.
- The current approach was to 'diff' between the base and head branch,
which seems logical but fail in practice when the pull request is out of
date with the base branch. Therefore it should instead diff between the
head branch and the merge base of the head and base branch, so only the
actual affected files by the pull requests are used, the same approach
is used by the diff of an unmerged pull request.
- Add integration testing (for the feature as well).
- Resolves#2458
In #2445, I lifted out the fork button into its own template, but did
not update it properly. This resulted in the fork button's counter not
displaying, and pointing to the wrong place too.
This patch updates the template to account for it moving to a separate
file, and also adds test cases to verify the button is display as it
should be.
Fixes#2494.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When viewing a tag that isn't associated with a release, highlight the
"N Tags" sub-menu item, rather than the "M releases" one.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The `repo.SingleRelease` handler was broken by gitea#29149, as the
switch to `getReleaseInfos` stopped returning tags without an associated
release. This resulted in the web UI showing a 404 when trying to view a
tag without a release.
This restores the functionality by explicitly including tags in the
search, and also adds tests to exercise the fix.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Fix#14459
The following users can add/remove review requests of a PR
- the poster of the PR
- the owner or collaborators of the repository
- members with read permission on the pull requests unit
(cherry picked from commit c42083a33950be6ee9f822c6d0de3c3a79d1f51b)
Conflicts:
models/repo/repo_list_test.go
tests/integration/api_nodeinfo_test.go
tests/integration/api_repo_test.go
shared fixture counts
Fixes the reason why #29101 is hard to replicate.
Related #29297
Create a repo with a file with minimum size 4097 bytes (I use 10000) and
execute the following code:
```go
gitRepo, err := gitrepo.OpenRepository(db.DefaultContext, <repo>)
assert.NoError(t, err)
commit, err := gitRepo.GetCommit(<sha>)
assert.NoError(t, err)
entry, err := commit.GetTreeEntryByPath(<file>)
assert.NoError(t, err)
b := entry.Blob()
// Create a reader
r, err := b.DataAsync()
assert.NoError(t, err)
defer r.Close()
// Create a second reader
r2, err := b.DataAsync()
assert.NoError(t, err) // Should be no error but is ErrNotExist
defer r2.Close()
```
The problem is the check in `CatFileBatch`:
79217ea63c/modules/git/repo_base_nogogit.go (L81-L87)
`Buffered() > 0` is used to check if there is a "operation" in progress
at the moment. This is a problem because we can't control the internal
buffer in the `bufio.Reader`. The code above demonstrates a sequence
which initiates an operation for which the code thinks there is no
active processing. The second call to `DataAsync()` therefore reuses the
existing instances instead of creating a new batch reader.
(cherry picked from commit f74c869221624092999097af38b6f7fae4701420)
Similarly to how `[repository].DISABLE_FORKS` works, lets make
`[repository].DISABLE_STARS` disable the routes too, not just hide the
functionality from the UI.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- If the user is searching repositories with an specific topic, adding
any other filter option, such as showing unrelevant repositories or
using another sort Forgejo should remember that 'topic only' was set.
- Adds integration test.
- Resolves#2461
If a documentation file is marked with a `linguist-documentation=false`
attribute, include it in language stats.
However, make sure that we do *not* include documentation languages as
fallback.
Added a new test case to exercise the formerly buggy behaviour.
Problem discovered while reviewing @KN4CK3R's tests from gitea#29267.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- If a user tries to create another protected branching rule that
specifies a set of branches already used by another rule, do not allow
it.
- Update the translation accordingly.
- Adds integration test.
- Resolves#2455
For small, personal self-hosted instances with no user signups, the fork
button is just a noise. This patch allows disabling them like stars can
be disabled too.
Disabling forks does not only remove the buttons from the web UI, it
also disables the routes that could be used to create forks.
Fixes#2441.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Check if someone is (accidentally) trying to create a pull request via
AGit with changes already in the target branch and fail if that is the
case.
- Added integration test.
Adds a label to Pull Requests that were created using AGit-Flow,
in order to prevent situations where a contributor uses AGit-Flow
to push new changes - only to realize that they did not use AGit-Flow
in the first place, and that they just opened a new PR accidentally
(that was me).
Also intended to raise general awareness about the feature. Some
additional work, such as adding a tooltip, still needs to be
done.
A small typo fix for a comment and (exclusively) formatting fixes
in the copyright header are also included.
Refs: https://codeberg.org/forgejo/forgejo/issues/2433
- The ambiguous character detection is an important security feature to
combat against sourcebase attacks (https://trojansource.codes/).
- However there are a few problems with the feature as it stands
today (i) it's apparantly an big performance hitter, it's twice as slow
as syntax highlighting (ii) it contains false positives, because it's
reporting valid problems but not valid within the context of a
programming language (ambiguous charachters in code comments being a
prime example) that can lead to security issues (iii) charachters from
certain languages always being marked as ambiguous. It's a lot of effort
to fix the aforementioned issues.
- Therefore, make it configurable in which context the ambiguous
character detection should be run, this avoids running detection in all
contexts such as file views, but still enable it in commits and pull
requests diffs where it matters the most. Ideally this also becomes an
per-repository setting, but the code architecture doesn't allow for a
clean implementation of that.
- Adds unit test.
- Adds integration tests to ensure that the contexts and instance-wide
is respected (and that ambigious charachter detection actually work in
different places).
- Ref: https://codeberg.org/forgejo/forgejo/pulls/2395#issuecomment-1575547
- Ref: https://codeberg.org/forgejo/forgejo/issues/564
Adds a very bare-bones test for artifact deletion. It does not exercise
the functionality itself, just the presence of the functionality.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
It's possible for reviews to not be assiocated with users, when they
were migrated from another forge instance. In the migration code,
there's no sanitization check for author names, so they could contain
HTML tags and thus needs to be properely escaped.
On the wiki and revisions page, information is shown about the last
commit that modified that wiki page. This includes the time it was last
edited and by whom. Verify it is sanitized.
- Currently there exists a restriction to not render and show files that
are larger than what's configured in `[UI].MAX_DISPLAY_FILE_SIZE`.
- Apply the same restriction to the blame operation as well, as the
blame operation can be seen as displaying a file.
- Add integration test.
- Ref: #2394
TLDR: Less code, better maintainability and more comments.
- Add code comments to explain what the code does, it's quite a big
function so it definitely deserved some of that.
- Simplify some logic.
- Load the `pusher` in a single place.
- Update the error messages to be more correct, not capitlized, include
more debug info and remove 'Error:' As it's no need to indicate that,
errors are concenated with `:` seperators.
- Improve the message that a change was rejected, because a force push
was detected and the `force-push` option wasn't set.
- Avoid a second time loading `gitRepo.GetObjectFormat` and handle the
error gracefully for the other occurence.
- Adds integration test for force push detection.
2 instances of `for` with a wrong value and 1 `for` that had a reference
to a `name` instead of `id`.
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
(cherry picked from commit 1d275c1748a75a01c270f5c306c5248808016aba)
This adds a few test cases to exercise the alert block feature of the
markdown renderer, both the legacy GitHub style, and the modern one.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- Move the conditions code around, such that the existence of the head
and base is first checked (so a clear error can be given, instead of a
possible server error). This makes it easier to read this code. As the
logic is now grouped together.
- Adds integration testing that simulates the deletion of the base and
head branch and ensures the pull request cannot be opened. The 'normal'
testcase also 'informally' ensures that the previous incorrect condition
is not there, because the branch `base-branch` doesn't exist on the head
repository.
- Resolves#2321
Rename `repo_lang_stats_test.go` to `linguist_test.go`, and add a new
tests that exercises parts of the web UI to ensure that language
overrides in `.gitattributes` work when viewing a file source, and in
the blame view too.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
The issue filter links should not be crawled by search engines, because
they they only filter results, and contain nothing new, yet, they put a
considerable load on the server.
To stop - well behaving - search engines from following these links, add
a `rel="nofollow"` property to them. The same property is already
present on the archive download links, and plenty of other places.
Fixes#2361.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Clarify when "string" should be used (and be escaped), and when
"template.HTML" should be used (no need to escape)
And help PRs like #29059 , to render the error messages correctly.
(cherry picked from commit f3eb835886031df7a562abc123c3f6011c81eca8)
Conflicts:
modules/web/middleware/binding.go
routers/web/feed/convert.go
tests/integration/branches_test.go
tests/integration/repo_branch_test.go
trivial context conflicts
Follow-up of #2282 and #2296 (which tried to address #2278)
One of the issue with the previous PR is that when a conversation on the Files tab was marked as "resolved", it would fetch all the comments for that line (even the outdated ones, which should not be shown on this page - except when explicitly activated).
To properly fix this, I have changed `FetchCodeCommentsByLine` to `FetchCodeConversation`. Its role is to fetch all comments related to a given (review, path, line) and reverted my changes in the template (which were based on a misunderstanding).
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2306
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: oliverpool <git@olivier.pfad.fr>
Co-committed-by: oliverpool <git@olivier.pfad.fr>
If no `-o description=` is provided, fill it in automatically from the
first commit, just like title. Also allow filling in either, and
specifying them independently.
This means that `git push origin HEAD:refs/for/main/my-local-branch`
will fill in the PR title, *and* the description, without having to
specify additional parameters.
The description is the first commit's message without the first two
lines (the title and a newline, as customary).
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
With this option, it is possible to require a linear commit history with
the following benefits over the next best option `Rebase+fast-forward`:
The original commits continue existing, with the original signatures
continuing to stay valid instead of being rewritten, there is no merge
commit, and reverting commits becomes easier.
Closes#24906
Fixes#2173
~~Still requires a bit of work to do, I'm not 100% happy with this solution.~~
The idea is to copy the noarch package to the architectures available in the package repository.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2285
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Alexandre Oliveira <me+codeberg@aoalmeida.com>
Co-committed-by: Alexandre Oliveira <me+codeberg@aoalmeida.com>
Skip a HookEventPullRequestSync event if it has the same CommitSHA as an existing HookEventPullRequest event in the ActionRun table. A HookEventPullRequestSync event must only create an ActionRun if the CommitSHA is different from what it was when the PR was open.
This guards against a race that can happen when the following is done in parallel:
* A commit C is pushed to a repo on branch B
* A pull request with head on branch B
it is then possible that the pull request is created first, successfully. The commit that was just pushed is not known yet but the PR only references the repository and the B branch so it is fine.
A HookEventPullRequest event is sent to the notification queue but not processed immediately.
The commit C is pushed and processed successfully. Since the PR already exists and has a head that matches the branch, the head of the PR is updated with the commit C and a HookEventPullRequestSync event is sent to the notification queue.
The HookEventPullRequest event is processed and since the head of the PR was updated to be commit C, an ActionRun with CommitSHA C is created.
The HookEventPullRequestSync event is then processed and also has a CommitSHA equal to C.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2314
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
This adds a new route at `/actions/workflows/{workflow}/runs/latest`,
which will redirect to the latest run of the given workflow. It can be
further restricted by specifying an optional `?branch={branch}` query
parameter. If no branch is specified, the route defaults to using the
repo's default branch.
This route is meant to go hand in hand with the Badge route that returns
the result of the same workflow as a badge. This route can be used to
link to the run that produced that result.
Fixes#2303.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Forking a repository via the web UI currently requires visiting a
`/repo/fork/{{repoid}}` URL. This makes it cumbersome to create a link
that starts a fork, because the repository ID is only available via the
API. While it *is* possible to create a link, doing so requires extra
steps.
To make it easier to have a "Fork me!"-style links, introduce the
`/{username}/{repo}/fork` route, which will start the forking process
based on the repository in context instead.
The old `/repo/fork/{repoid}` route (with a `GET` request) will remain
there for the sake of backwards compatibility, but will redirect to the
new URL instead. It's `POST` handler is removed.
Tests that used the old route are updated to use the new one, and new
tests are introduced to exercise the redirect.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This adds a few tests for the previous change, to verify that issue
template configs, issue templates and pr templates are all recognized in
`.forgejo` directories.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When issue templates were moved into services in
def4956122, the code was also refactored
and simplified. Unfortunately, that simplification broke the
`/api/v1/{owner}/{repo}/issue_templates` route, because it was
previously using a helper function that ignored invalid templates, and
after the refactor, the function it called *always* returned non-nil as
the second return value. This, in turn, results in the aforementioned
end point always returning an internal server error.
This change restores the previous behaviour of ignoring invalid files
returned by `issue.GetTemplatesFromDefaultBranch`, and adds a few test
cases to exercise the endpoint.
Other users of `GetTemplatesFromDefaultBranch` already ignore the second
return value, or handle it correctly, so no changes are necessary there.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
* Split TestPullRequest out of AddTestPullRequestTask
* Before scheduling the task, AddTestPullRequestTask stores the max
index of the repository
* When the task runs, it does not take into account pull requests that
have an index higher than the recorded max index
When AddTestPullRequestTask is called with isSync == true, it is the
direct consequence of a new commit being pushed. Forgejo knows nothing
of this new commit yet. If a PR is created later and its head
references the new commit, it will have an index that is higher and
must not be taken into account. It would be acting and triggering a
notification for a PR based on an event that happened before it
existed.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2236
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
(cherry picked from commit b3be895a30)
The "Self Check" menu essentially runs the collation check that is also
performed at startup, and displays the results. This is only a thing for
MariaDB/MySQL and MSSQL. As such, the menu item should only be available
for these database types.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 0ca118fdc3)
