- 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)
Because Forgejo run mysqld with `--innodb-flush-method=nosync` to speed
up the test suite, there are situations where a larger, database-wide
operation does not always fully manifest until later, not even when it
is wrapped in a transaction, nor when we use `FLUSH TABLES` and similar
methods.
In the case of the MySQL collation test, this *sometimes* results in the
database still responding with the old collation to a reader, even after
an `ALTER DATABASE ... COLLATE ...`.
In order to be able to still use the aforementioned flag and enjoy its
benefits, add a five second sleep between `db.ConvertDatabaseTable()`
and `db.CheckCollations()` in the `TestDatabaseCollation()` set of
tests.
This is not a fix - I don't think there is one possible -, but a
workaround. If it breaks again, the correct fix will be to remove the
flag from `mysqld` (it's not a supported flag to begin with).
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit af18ed2ba9)
Previously, the repo wiki was hardcoded to use `master` as its branch,
this change makes it possible to use `main` (or something else, governed
by `[repository].DEFAULT_BRANCH`, a setting that already exists and
defaults to `main`).
The way it is done is that a new column is added to the `repository`
table: `wiki_branch`. The migration will make existing repositories
default to `master`, for compatibility's sake, even if they don't have a
Wiki (because it's easier to do that). Newly created repositories will
default to `[repository].DEFAULT_BRANCH` instead.
The Wiki service was updated to use the branch name stored in the
database, and fall back to the default if it is empty.
Old repositories with Wikis using the older `master` branch will have
the option to do a one-time transition to `main`, available via the
repository settings in the "Danger Zone". This option will only be
available for repositories that have the internal wiki enabled, it is
not empty, and the wiki branch is not `[repository].DEFAULT_BRANCH`.
When migrating a repository with a Wiki, Forgejo will use the same
branch name for the wiki as the source repository did. If that's not the
same as the default, the option to normalize it will be available after
the migration's done.
Additionally, the `/api/v1/{owner}/{repo}` endpoint was updated: it will
now include the wiki branch name in `GET` requests, and allow changing
the wiki branch via `PATCH`.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d87c526d2a)
- When a commit references a pull request, the detail strings should
reflect that. Add a new translation string for the pull request.
- Added integration tests.
- Resolves#2256
(cherry picked from commit 0d054cd4d9)
These tests originate from Gitea, so may cause conflicts in the longer
run. But they use the same pattern, so transitioning them to the helper
is hopefully a benefit that offsets the risk.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 2d475af494)
(cherry picked from commit a99c17729c)
There are a number of tests which require creating a repository on the
fly, and they each do it their own way. To reduce code duplication, lift
out this common pattern into a helper called `CreateDeclarativeRepo()`,
which lets us create a repository, set up enabled and disabled repo
units, and even add, delete, or update files.
Also convert a number of users of this pattern to the new helper - those
users that I introduced, and are in code introduced by Forgejo in the
first place.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 342b7bae3c)
(cherry picked from commit 2ece8764e9)
When displaying the recently pushed branches banner, don't display
branches that have no common history with the default branch. These
branches are usually not meant to be merged, so the banner is just noise
in this case.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2196
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e1fba517f4)
(cherry picked from commit 2d3c81d4f2)
(cherry picked from commit 624a61b3b8)
When comparing branches, only offer those branches to use as a base
where the repository allows pull requests. Those that do not allow pull
request would result in a 404, so offering them as an option would be
misleading.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2194
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 022d0e0d71)
(cherry picked from commit 957990b36a)
(cherry picked from commit 6d2df72825)
With this change, the "You pushed on branch xyz" banner will be
displayed when either the viewed repository or its base repo (if the
current one's a fork) has pull requests enabled. Previously it only
displayed if the viewed repo had PRs enabled.
Furthermore, if the viewed repository is an original repository that the
viewing user has a fork of, if the forked repository has recently pushed
branches, then the banner will appear for the original repository too.
In this case, the notification will include branches from the viewing
user's fork, and branches they pushed to the base repo, too.
Refs: https://codeberg.org/forgejo/forgejo/pulls/2195
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit a29f10661d)
(cherry picked from commit 70c5e2021d)
(cherry picked from commit 48b25be67a)
- Document the correct content types for Git archives. Add code that
actually sets the correct application type for `.zip` and `.tar.gz`.
- When an action (POST/PUT/DELETE method) was successful, an 204 status
code should be returned instead of status code 200.
- Add and adjust integration testing.
- Resolves#2180
- Resolves#2181
(cherry picked from commit 6c8c4512b5)
(cherry picked from commit 3f74bcb14d)
(cherry picked from commit 6ed9057fd7)
Recognise the `linguist-documentation` and `linguist-detectable`
attributes in `.gitattributes` files, and use them in
`GetLanguageStats()` to make a decision whether to include a particular
file in the stats or not.
This allows one more control over which files in their repositories
contribute toward the language statistics, so that for a project that is
mostly documentation, the language stats can reflect that.
Fixes#1672.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 6d4e02fe5f)
(cherry picked from commit ee1ead8189)
(cherry picked from commit 2dbec730e8)
When searching for repository topics, either via the API, or via
Explore, paging did not work correctly, because it only applied when the
`page` parameter was non-zero. Paging should have applied when the page
size is greater than zero, which is what this patch does.
As a result, both the API, and the Explore endpoint will return paged
results (30 by default). As such, when managing topics on the frontend,
the offered completions will also be limited to a pageful of results,
based on what the user has already typed.
This drastically reduces the amount of traffic, and also the number of
the topics to choose from, and thus, the rendering time too.
The topics will be returned by popularity, with most used topics first.
A single page will contain `[api].DEFAULT_PAGING_NUM` (30 by default)
items that match the query. That's plenty to choose from.
Fixes#132.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 64d4ff41db)
(cherry picked from commit 06b808fa2c)
(cherry picked from commit 9205c9266a)
(cherry picked from commit 47863d4f72)
services: in loadOneBranch, return if CountDivergingCommits fail
If we can't count the number of diverging commits for one reason or
another (such as the branch being in the database, but missing from
disk), rather than logging an error and continuing into a crash (because
`divergence` will be nil), return an error instead.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 8266105f24)
services: Gracefully handle missing branches
When loading branches, if loading one fails, log an error, and ignore
the branch, rather than returning and causing an internal server error.
Ideally, we would only ignore the error if it was caused by a missing
branch, and do it silently, like the respective API endpoint does.
However, veryfing that at this place is not very practical, so for the
time being, ignore any and all branch loading errors.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e552a8fd62)
tests: Add a testcase for missing branches
This tests the scenario reported in Codeberg/Community#1408: a branch
that is recorded in the database, but missing on disk was causing
internal server errors. With recent changes, that is no longer the case,
the error is logged and then ignored.
This test case tests this behaviour, that the repo's branches page on
the web UI functions even if the git branch is missing.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit e20eb7b385)
tests: More testing in TestDatabaseMissingABranch
In the `TestDatabaseMissingABranch` testcase, make sure that the
branches are in sync between the db and git before deleting a branch via
git, then compare the branch count from the web UI, making sure that it
returns an out-of-sync value first, and the correct one after another
sync.
This is currently tested by scraping the UI, and relies on the fact that
the branch counter is out of date before syncing. If that issue gets
resolved, we'll have to adjust the test to verify the sync another way.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 8c2ccfcece)
(cherry picked from commit 439fadf563)
(cherry picked from commit 44dd80552c)
(cherry picked from commit 37b91fe6f2)
- It's possible that `canSoftDeleteContentHistory` is called without
`ctx.Doer` being set, such as an anonymous user requesting the
`/content-history/detail` endpoint.
- Add a simple condition to always set to `canSoftDelete` to false if an
anonymous user is requesting this, this avoids a panic in the code that
assumes `ctx.Doer` is set.
- Added integration testing.
(cherry picked from commit 0b5db0dcc6)
(cherry picked from commit 30d168bcc8)
(cherry picked from commit 19be82b7ef)
(cherry picked from commit 334b703b17)
Refs: https://codeberg.org/forgejo/forgejo/issues/2109
(cherry picked from commit 8b4ba3dce7)
(cherry picked from commit 196edea0f9)
[GITEA] POST /repos/{owner}/{repo}/pulls/{index}/reviews/{id}/comments (squash) do not implicitly create a review
If a comment already exists in a review, the comment is added. If it
is the first comment added to a review, it will implicitly create a
new review instead of adding to the existing one.
The pull_service.CreateCodeComment function is responsibe for this
behavior and it will defer to createCodeComment once the review is
determined, either because it was found or because it was created.
Rename createCodeComment into CreateCodeCommentKnownReviewID to expose
it and change the API endpoint to use it instead. Since the review is
provided by the user and verified to exist already, there is no need
for the logic implemented by CreateCodeComment.
The tests are modified to remove the initial comment from the fixture
because it was creating the false positive. I was verified to fail
without this fix.
(cherry picked from commit 6a555996dc)
(cherry picked from commit b173a0ccee)
(cherry picked from commit 838ab9740a)
Expose the repository flags feature over the API, so the flags can be
managed by a site administrator without using the web API.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit bac9f0225d)
(cherry picked from commit e7f5c1ba14)
(cherry picked from commit 95d9fe19cf)
(cherry picked from commit 7fc51991e4)
This implements "repository flags", a way for instance administrators to
assign custom flags to repositories. The idea is that custom templates
can look at these flags, and display banners based on them, Forgejo does
not provide anything built on top of it, just the foundation. The
feature is optional, and disabled by default. To enable it, set
`[repository].ENABLE_FLAGS = true`.
On the UI side, instance administrators will see a new "Manage flags"
tab on repositories, and a list of enabled tags (if any) on the
repository home page. The "Manage flags" page allows them to remove
existing flags, or add any new ones that are listed in
`[repository].SETTABLE_FLAGS`.
The model does not enforce that only the `SETTABLE_FLAGS` are present.
If the setting is changed, old flags may remain present in the database,
and anything that uses them, will still work. The repository flag
management page will allow an instance administrator to remove them, but
not set them, once removed.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit ba735ce222)
(cherry picked from commit f09f6e029b)
(cherry picked from commit 2f8b041489)
(cherry picked from commit d3186ee5f4)
