Back in #2264, we made it possible to change the branch wikis use from
the hardcoded "master" branch to `[repository].DEFAULT_BRANCH`. However,
the API endpoints were not updated, and the "master" branch remained
hardcoded there.
This change fixes that, the API endpoints will now respect the
repository's `WikiBranch`.
Fixes#3391.
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>
Add some logic in `convert.ToBranchProtection` to return only the names
associated with readAccess instead of returning all names. This will
ensure consistency in behavior between the frontend and backend.
Fixes: #27694
---------
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wenzhuo.zhang <wenzhuo.zhang@geely.com>
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 02e183bf3fa502b7cef76e8dcdbf01b85ce641f0)
- 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.
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>
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>
Fix#30378
(cherry picked from commit 0fe9f93eb4c94d55e43b18b9c3cc6d513a34c0b5)
Conflicts:
- models/organization/org.go
- services/repository/delete.go
- services/user/delete.go
In all three cases, conflicts were resolved by manually adding
the lines added by the Gitea patch, keeping the Forgejo code
surrounding them.
This PR do some performance optimzations.
- [x] Add `index` for the column `comment_id` of `Attachment` table to
accelerate query from the database.
- [x] Remove unnecessary database queries when viewing issues. Before
some conditions which id = 0 will be sent to the database
- [x] Remove duplicated load posters
- [x] Batch loading attachements, isread of comments on viewing issue
---------
Co-authored-by: Zettat123 <zettat123@gmail.com>
Conflicts:
models/issues/comment_code.go: function was renamed in Forgejo
models/migrations/migrations.go: migration already ported
- Adds setting `EXTERNAL_USER_DISABLE_FEATURES` to disable any supported
user features when login type is not plain
- In general, this is necessary for SSO implementations to avoid
inconsistencies between the external account management and the linked
account
- Adds helper functions to encourage correct use
(cherry picked from commit 59d4aadba5c15d02f3b9f0e61abb7476870c20a5)
Conflicts:
- docs/content/administration/config-cheat-sheet.en-us.md
Removed.
- modules/setting/admin.go
Trivial resolution: pick the newly added struct member.
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)
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
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
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>
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>
(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)
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)
Add two "HTMLURL" methods for PackageDescriptor.
And rename "FullWebLink" to "VersionWebLink"
(cherry picked from commit bf6502a8f7a2e9a2b64b43b7733316d863c9a768)
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)
just some refactoring bits towards replacing **util.OptionalBool** with
**optional.Option[bool]**
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit f6656181e4a07d6c415927220efa2077d509f7c6)
Conflicts:
models/repo/repo_list_test.go
trivial shared fixture count conflicts
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 was incorrectly copied from the `swaggerCommitList` struct, which
on the other hand does set `X-Total`, but the API handler that uses this
response only sets `X-Total-Count`.
- Update github.com/bufbuild/connect-go to
https://github.com/connectrpc/connect-go.
- This is a fork that's actively maintained and is recommend by the
original library. Looking at the recent release notes, it looks like
going in the right direction what one would expect of a library, no
strange features being added, lots of improvements.
- There's still an indirect dependency by
`code.gitea.io/actions-proto-go` on a old version of `connect-go`.
Adds a new API `/repos/{owner}/{repo}/commits/{sha}/pull` that allows
you to get the merged PR associated to a commit.
---------
Co-authored-by: 6543 <6543@obermui.de>
(cherry picked from commit 0a426cc575734e5eff410d6a790f40473117f753)
Now we can get object format name from git command line or from the
database repository table. Assume the column is right, we don't need to
read from git command line every time.
This also fixed a possible bug that the object format is wrong when
migrating a sha256 repository from external.
<img width="658" alt="image"
src="https://github.com/go-gitea/gitea/assets/81045/6e9a9dcf-13bf-4267-928b-6bf2c2560423">
(cherry picked from commit b79c30435f439af8243ee281310258cdf141e27b)
Conflicts:
routers/web/repo/blame.go
services/agit/agit.go
context
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>
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>
Follow #29165.
* Introduce JSONTemplate to help to render JSON templates
* Introduce JSEscapeSafe for templates. Now only use `{{ ... |
JSEscape}}` instead of `{{ ... | JSEscape | Safe}}`
* Simplify "UserLocationMapURL" useage
(cherry picked from commit 31bb9f3247388b993c61a10190cfd512408ce57e)
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
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>
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>
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 there's a succesful POST operation, it should return a 201 status
code (which is the status code for succesful created) and additionally
the created object.
- Currently for the `POST /repos/{owner}/{repo}/tags` endpoint an 200
status code was documented in the OpenAPI specification, while an 201
status code was actually being returned. In this case the code is
correct and the documented status code needs to be adjusted.
- Resolves#2200
(cherry picked from commit a2939116f5)
(cherry picked from commit 22cff41585)
(cherry picked from commit b23a7f27bb)
- The name could be conflucted with the `GET
/user/applications/oauth2/{id}` operation, as it only differed in a
single letter being uppercase. Change it to be
userGetOAuth2Application**s**, as that's also more accurate for this function.
- Resolves#2163
(cherry picked from commit 1891dac547)
(cherry picked from commit 68fceb9b7a)
(cherry picked from commit 7335d6de54)
- 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)
Instead of repeating the tests that verify the ID of a comment
is related to the repository of the API endpoint, add the middleware
function commentAssignment() to assign ctx.Comment if the ID of the
comment is verified to be related to the repository.
There already are integration tests for cases of potential unrelated
comment IDs that cover some of the modified endpoints which covers the
commentAssignment() function logic.
* TestAPICommentReactions - GetIssueCommentReactions
* TestAPICommentReactions - PostIssueCommentReaction
* TestAPICommentReactions - DeleteIssueCommentReaction
* TestAPIEditComment - EditIssueComment
* TestAPIDeleteComment - DeleteIssueComment
* TestAPIGetCommentAttachment - GetIssueCommentAttachment
The other modified endpoints do not have tests to verify cases of
potential unrelated comment IDs. They no longer need to because they
no longer implement the logic to enforce this. They however all have
integration tests that verify the commentAssignment() they now rely on
does not introduce a regression.
* TestAPIGetComment - GetIssueComment
* TestAPIListCommentAttachments - ListIssueCommentAttachments
* TestAPICreateCommentAttachment - CreateIssueCommentAttachment
* TestAPIEditCommentAttachment - EditIssueCommentAttachment
* TestAPIDeleteCommentAttachment - DeleteIssueCommentAttachment
(cherry picked from commit d414376d74)
(cherry picked from commit 09db07aeae)
(cherry picked from commit f44830c3cb)
Conflicts:
modules/context/api.go
https://codeberg.org/forgejo/forgejo/pulls/2249
(cherry picked from commit 9d1bf7be15)
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)
- Switch the supported schemas for the Swagger API around, such that
https is the first one listed. This ensures that when the Swagger API is
used it will default to the https schema, which is likely the schema you
want to use in the majority of the cases.
- Resolves#1895
BREAKING CHANGE NOTICE:
If you are using the Swagger API JSON directly to communicate with the
Forgejo API, the library you are using may be using the first schema
defined in the JSON file (e.g. https://code.forgejo.org/swagger.v1.json)
to construct the request url, this used to be `http` but has now changed
to `https`. This can cause failures if you want to send the swagger
request over `http` (and there is no HTTPS redirection configured).
(cherry picked from commit 81e5f43886)
(cherry picked from commit d847469ea2)
(cherry picked from commit 96e75e1d5c)
(cherry picked from commit 65baa64261)
(cherry picked from commit cd3e0a74e6)
(cherry picked from commit a3127e90b2)
(cherry picked from commit 2b22272dc5)
(cherry picked from commit 7363790592)
(cherry picked from commit 432b9a4451)
