This allows `nix flake metadata` and nix in general to lock a *branch*
tarball link in a manner that causes it to fetch the correct commit even
if the branch is updated with a newer version.
For further context, Nix flakes are a feature that, among other things,
allows for "inputs" that are "github:someuser/somerepo",
"https://some-tarball-service/some-tarball.tar.gz",
"sourcehut:~meow/nya" or similar. This feature allows our users to fetch
tarballs of git-based inputs to their builds rather than using git to
fetch them, saving significant download time.
There is presently no gitea or forgejo specific fetcher in Nix, and we
don't particularly wish to have one. Ideally (as a developer on a Nix
implementation myself) we could just use the generic tarball fetcher and
not add specific forgejo support, but to do so, we need additional
metadata to know which commit a given *branch* tarball represents, which
is the purpose of the Link header added here.
The result of this patch is that a Nix user can specify `inputs.something.url =
"https://forgejo-host/some/project/archive/main.tar.gz"` in flake.nix
and get a link to some concrete tarball for the actual commit in the
lock file, then when they run `nix flake update` in the future, they
will get the latest commit in that branch.
Example of it working locally:
» nix flake metadata --refresh 'http://localhost:3000/api/v1/repos/jade/cats/archive/main.tar.gz?dir=configs/nix'
Resolved URL: http://localhost:3000/api/v1/repos/jade/cats/archive/main.tar.gz?dir=configs/nix
Locked URL: 804ede182b.tar.gz?dir=configs
/nix&narHash=sha256-yP7KkDVfuixZzs0fsqhSETXFC0y8m6nmPLw2GrAMxKQ%3D
Description: Computers with the nixos
Path: /nix/store/s856c6yqghyan4v0zy6jj19ksv0q22nx-source
Revision: 804ede182b6b66469b23ea4d21eece52766b7a06
Last modified: 2024-05-02 00:48:32
For details on the header value, see:
56763ff918/doc/manual/src/protocols/tarball-fetcher.md
(cherry picked from commit 6631f56ebf)
Fix#30921
(cherry picked from commit 821d2fc2a3cc897f21d707455850177077b72410)
(cherry picked from commit 50b4e7f26e)
Equivalent to the Gitea v1.22 commit
(cherry picked from commit 8eac16de217978c1f7034f8e360f54d8d638e95e)
Fix#30923
(cherry picked from commit effb405cae88474c27f5c8322a2627019af1cf64)
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Conflicts:
- modules/setting/oauth2.go
Conflicted due to different ways of logging. Since the log
message is removed anyway, resolved by removing it.
- modules/setting/oauth2_test.go
Manually copied the test added by Gitea.
- routers/install/install.go
Not a conflict per se, but adjusted to use NewJwtSecret().
(cherry picked from commit 193ac67176)
Equivalent to the Gitea v1.22 commit
(cherry picked from commit 5b7e54f72f7b85b3394d7af20b27152d26e26256)
Previously, if no branch was explicitly specified for a workflow, it
defaulted to the default branch of the repo. This worked fine for
workflows that were triggered on push, but it prevented showing badges
for workflows that only run on tags, or on schedule - since they do not
run on a specific branch.
Thus, relax the conditions, and if no branch is specified, just return
the latest run of the given workflow. If one is specified, *then*
restrict it to said branch.
Fixes#3487.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit d6915f4d5f)
Backport #27821 by @lunny
When a user logout and then login another user, the reverseproxy auth
should be checked before session otherwise the old user is still login.
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
(cherry picked from commit 14dc00ae01c35ad51a3982a5725777bbeabe2b78)
The previous implementation will start multiple POST requests from the
frontend when moving a column and another bug is moving the default
column will never be remembered in fact.
- [x] This PR will allow the default column to move to a non-first
position
- [x] And it also uses one request instead of multiple requests when
moving the columns
- [x] Use a star instead of a pin as the icon for setting the default
column action
- [x] Inserted new column will be append to the end
- [x] Fix#30701 the newly added issue will be append to the end of the
default column
- [x] Fix when deleting a column, all issues in it will be displayed
from UI but database records exist.
- [x] Add a limitation for columns in a project to 20. So the sorting
will not be overflow because it's int8.
---------
Co-authored-by: silverwind <me@silverwind.io>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit a303c973e0264dab45a787c4afa200e183e0d953)
Conflicts:
routers/web/web.go
e91733468ef726fc9365aa4820cdd5f2ddfdaa23 Add missing database transaction for new issue (#29490) was not cherry-picked
services/issue/issue.go
fe6792dff3 Enable/disable owner and repo projects independently (#28805) was not cherry-picked
(cherry picked from commit 7d3ca90dfe)
(cherry picked from commit 084bec89ed7ae0816fc2d8db6784ad22523d1fc4)
Merging PR may fail because of various problems. The pull request may
have a dirty state because there is no transaction when merging a pull
request. ref
https://github.com/go-gitea/gitea/pull/25741#issuecomment-2074126393
This PR moves all database update operations to post-receive handler for
merging a pull request and having a database transaction. That means if
database operations fail, then the git merging will fail, the git client
will get a fail result.
There are already many tests for pull request merging, so we don't need
to add a new one.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit ebf0c969403d91ed80745ff5bd7dfbdb08174fc7)
Conflicts:
modules/private/hook.go
routers/private/hook_post_receive.go
trivial conflicts because
263a716cb5 * Performance optimization for git push (#30104)
was not cherry-picked and because of
998a431747 Do not update PRs based on events that happened before they existed
(cherry picked from commit eb792d9f8a)
(cherry picked from commit ec3f5f9992d7ff8250c044a4467524d53bd50210)
similar to #30784 but only for the repo explore page
is covered by #30876 for the main branch
(cherry picked from commit d410e2acce22e5b3518a9bf64a9152b32a91fe18)
Before explaining the fix itself, lets look at the `action` table, and
how it is populated. Data is only ever inserted into it via
`activities_model.NotifyWatchers`, which will:
- Insert a row for each activity with `UserID` set to the acting user's
ID - this is the original activity, and is always inserted if anything
is to be inserted at all.
- It will insert a copy of each activity with the `UserID` set to the
repo's owner, if the owner is an Organization, and isn't the acting
user.
- It will insert a copy of each activity for every watcher of the repo,
as long as the watcher in question has read permission to the repo
unit the activity is about.
This means that if a repository belongs to an organizations, for most
activities, it will have at least two rows in the table. For
repositories watched by people other than their owner, an additional row
for each watcher.
These are useful duplicates, because they record which activities are
relevant for a particular user. However, for cases where we wish to see
the activities that happen around a repository, without limiting the
results to a particular user, we're *not* interested in the duplicates
stored for the watchers and the org. We only need the originals.
And this is what this change does: it introduces an additional option to
`GetFeedsOptions`: `OnlyPerformedByActor`. When this option is set,
`activities.GetFeeds()` will only return the original activities, where
the user id and the acting user id are the same. As these are *always*
inserted, we're not missing out on any activities. We're just getting
rid of the duplicates. As this is an additional `AND` condition, it can
never introduce items that would not have been included in the result
set before, it can only reduce, not extend.
These duplicates were only affecting call sites where `RequestedRepo`
was set, but `RequestedUser` and `RequestedTeam` were not. Both of those
call sites were updated to set `OnlyPerformedByActor`. As a result,
repository RSS feeds, and the `/repos/{owner}/{repo}/activities/feeds`
API end points no longer return dupes, only the original activities.
Rather than hardcoding this behaviour into `GetFeeds()` itself, I chose
to implement it as an explicit option, for the sake of clarity.
FixesCodeberg/Community#684, and addresses gitea#20986.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit 9cb2aa989a)
Fix#30807
reuse functions in services
(cherry picked from commit a50026e2f30897904704895362da0fb12c7e5b26)
Conflicts:
models/issues/issue_update.go
routers/api/v1/repo/issue.go
trivial context conflict because of 'allow setting the update date on issues and comments'
(cherry picked from commit 6a4bc0289d)
We should be listing all repositories by default.
Fixes#28483.
(cherry picked from commit 9f0ef3621a3b63ccbe93f302a446b67dc54ad725)
Conflict:
- if ctx.IsSigned && ctx.Doer.IsAdmin || permission.UnitAccessMode(unit_model.TypeCode) >= perm.AccessModeRead {
+ if ctx.IsSigned && ctx.Doer.IsAdmin || permission.HasAccess() {
because of https://codeberg.org/forgejo/forgejo/pulls/2001
(cherry picked from commit e388822e9d)
Backport #30790 by archer-321
This commit forces the resource owner (user) to always approve OAuth 2.0
authorization requests if the client is public (e.g. native
applications).
As detailed in [RFC 6749 Section
10.2](https://www.rfc-editor.org/rfc/rfc6749.html#section-10.2),
> The authorization server SHOULD NOT process repeated authorization
requests automatically (without active resource owner interaction)
without authenticating the client or relying on other measures to ensure
that the repeated request comes from the original client and not an
impersonator.
With the implementation prior to this patch, attackers with access to
the redirect URI (e.g., the loopback interface for
`git-credential-oauth`) can get access to the user account without any
user interaction if they can redirect the user to the
`/login/oauth/authorize` endpoint somehow (e.g., with `xdg-open` on
Linux).
Fixes#25061.
Co-authored-by: Archer <archer@beezig.eu>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 6d83f5eddc0f394f6386e80b86a3221f6f4925ff)
Before, we would just throw 500 if a user passes an attachment that is
not an allowed type. This commit catches this error and throws a 422
instead since this should be considered a validation error.
(cherry picked from commit 872caa17c0a30d95f85ab75c068d606e07bd10b3)
Conflicts:
tests/integration/api_comment_attachment_test.go
tests/integration/api_issue_attachment_test.go
trivial context conflict because of 'allow setting the update date on issues and comments'
(cherry picked from commit 9cd0441cd3)
When subscribing or unsubscribing to/from an issue on the web ui, the
request was posted to a route handled by `repo.IssueWatch`. This
function used `ctx.Req.PostForm.Get()`, erroneously.
`request.PostForm` is *only* available if `request.ParseForm()` has been
called before it. The function in question did not do that. Under some
circumstances, something, somewhere did end up calling `ParseForm()`,
but not in every scenario.
Since we do not need to check for multiple values, the easiest fix here
is to use `ctx.Req.PostFormValue`, which will call `ParseForm()` if
necessary.
Fixes#3516.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When all repository units are deactivated except for the code unit, the activity tab will not be shown.
Since the activities tab also shows contributing stats, it would be good to show the activities tab also when only code is active.
This commit changes the behavior when the activities tab is shown.
Previous it would only be shown when Issues, Pull-Requests or Releases are activated. Now it would additionally be shown when the code unit is activated.
Refs: #3429
| Before (Code + Issues - Owner) | Before (Code - Viewer) | After (Code + Issues - Owner) | After (Code - Viewer) |
| -- | -- | -- | -- |
|  |  |  |  |
| | `/activity` returns 404 for everyone |  | - |
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3455
Reviewed-by: Otto <otto@codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
(cherry picked from commit c54896ba70)
Backport #30291 by @edwardzhanged
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: Edward Zhang <45360012+edwardzhanged@users.noreply.github.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.com>
Co-authored-by: wenzhuo.zhang <wenzhuo.zhang@geely.com>
(cherry picked from commit d88958bb99eabc07dead6965e396755e7b6d947f)
Backport #30511 by @yp05327
Fix#30508
ps: if `sourceID` is not set, `LoginName` will be ignored
Co-authored-by: yp05327 <576951401@qq.com>
(cherry picked from commit f9a025f6a358aa6e34408743a59f5081f397d47c)
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>
(cherry picked from commit 8eba631f8d)
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.
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)
(cherry picked from commit db39b8f4a7)
`log.Xxx("%v")` is not ideal, this PR adds necessary context messages.
Remove some unnecessary logs.
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 83f83019ef3471b847a300f0821499b3896ec987)
Conflicts:
- modules/util/util.go
Conflict resolved by picking `util.Iif` from 654cfd1dfbd3f3f1d94addee50b6fe2b018a49c3
(cherry picked from commit 492d116b2a468991f44d6d37ec33f918ccbe4514)
Conflicts:
modules/util/util.go
trivial context conflict as the commit is picked from https://codeberg.org/forgejo/forgejo/pulls/3212
* 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
(cherry picked from commit 998a431747)
Conflicts:
models/forgejo_migrations/migrate.go
see https://codeberg.org/forgejo/forgejo/pulls/3165#issuecomment-1755941
services/pull/pull.go
trivial conflicts
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/3046
This PR fixes an issue in the diff compare view, where when working on a fork that has not the same name as the upstream repo, the "View file" button links to a wrong, often missing, location.
Demonstration of this issue:
- Visit https://next.forgejo.org/mai-lapyst-test-org/upstream/compare/main...Mai-Lapyst/downstream:mai-lapyst-patch-1.
- Click the "View file" button of the patch.
- Get taken to `4fe947d522/README.md` (which does not exist and returns a 404) instead of `4fe947d522/README.md`. Note the different repository name (`upstream` vs `downstream`).
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3077
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
**Backport:** https://codeberg.org/forgejo/forgejo/pulls/1518
An attempt at adding an optional pronoun field for user profiles, as suggested here 3 years ago: https://github.com/go-gitea/gitea/issues/13990
I made this for [my own instance](https://git.gay/h) and didn't initially think I'd make a PR because of the previous closed issue, but I thought I'd ask the Forgejo matrix chat to see if there was any support and there was!
I'm told I should make a database migration, some help as to how to do that would be appreciated.
Co-authored-by: hazycora <hazysu@riseup.net>
Co-authored-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3076
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
Co-committed-by: forgejo-backport-action <forgejo-backport-action@noreply.codeberg.org>
