Follow https://github.com/go-gitea/gitea/pull/30357
When user push to default branch, the schedule trigger user will be the
user.
When disable then enable action units in settings, the schedule trigger
user will be action user.
When repo is a mirror, the schedule trigger user will be action user. (
before it will return error, fixed by #30357)
As scheduled job is a cron, the trigger user should be action user from
Gitea, not a real user.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit cb6814adad4dc81a683b50826a211ce7bce731d7)
Conflicts:
- services/actions/notifier_helper.go
Conflict resolved by keeping Forgejo's version of the line.
(cherry picked from commit 829c3c6838)
Backport #30584 by @wolfogre
Related to #30375.
It doesn't make sense to import `modules/web/middleware` and
`modules/setting` in `modules/web/session` since the last one is more
low-level.
And it looks like a workaround to call `DeleteLegacySiteCookie` in
`RegenerateSession`, so maybe we could reverse the importing by
registering hook functions.
Co-authored-by: Jason Song <i@wolfogre.com>
(cherry picked from commit 199397a852ec2d45524cefcc3c119fce4710560e)
Backport #30548 by @silverwind
Fixes https://github.com/go-gitea/gitea/issues/28114 and behaviour
matches vscode on desktop as well.
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit c9633f2d74490211ffd9fd6b3a17180e86fa1fb9)
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)
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.
(cherry picked from commit 3918db10c8)
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)
Backport #30484 by @silverwind
Small tweak here to prevent this and likely other events from
overflowing in the timeline:
<img width="895" alt="Screenshot 2024-04-14 at 22 53 17"
src="https://github.com/go-gitea/gitea/assets/115237/001b4f6b-f649-44ff-b2f0-c8e0dedeb384">
Co-authored-by: silverwind <me@silverwind.io>
(cherry picked from commit 2efc81d200106cd8707dae1a1bf50ea586b4c846)
Unify the behaviors of "user create" and "user change-password".
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 4c6e2da088cf092a9790df5c84b7b338508fede7)
Conflicts:
- cmd/admin_user_create.go
Resolved by favoring Gitea's version of the conflicting areas.
- docs/content/administration/command-line.en-us.md
Removed, Gitea specific.
(cherry picked from commit b122c6ef8b)
Backport #30375 by @jtran
Cookies may exist on "/subpath" and "/subpath/" for some legacy reasons
(eg: changed CookiePath behavior in code). The legacy cookie should be
removed correctly.
Co-authored-by: Jonathan Tran <jonnytran@gmail.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Kyle D <kdumontnu@gmail.com>
(cherry picked from commit e64926c5193e9ccc30b34f187d96c74d104179ae)
- Fixes wrong usage of AppURL
- Fixes wrong rendering with extra path segments when AppSubURL is empty
- Now also renders all links when 2+ permalinks are present
(cherry picked from commit 5b6b3f3fb3)
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)
Ref https://codeberg.org/forgejo/forgejo/issues/2831
Removed from:
- form for creating comment
- form for updating comment
- popup reviewing form
- line reviewing form
- I did not check the use of textarea.tmpl but I belive its used for issue templates, so also removed
- I did not check the use of box.tmpl, could not get any comments on compare
EasyMDE is left for these pages:
- release notes editor
- wiki editor
(cherry picked from commit 703aee4cad)
When sending notification emails about a release, use a properly
formatted, RFC-compliant message id, rather than the release's HTML URL
wrapped in angle brackets (which would not be compliant).
Fixes#3105.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
(cherry picked from commit b0c0167c54)
The ARG RELEASE_VERSION set in the build-env image does not propagate
to the images that follow. As a result the value of the version label
is always empty.
This should have been caught by the test in the CI but although it
notified the problem in the output, it did not fail. Upgrade to the
forgejo-build-publish version that fixes this false positive.
(cherry picked from commit 97189d41f3)
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>
(cherry picked from commit ea4071ca9f)
- 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
(cherry picked from commit a0f47b8de7)
- This is a partial revert of c2280a2009,
it was already fixed upstream, but not for the `.basic` variant.
- Resolves#3252
(cherry picked from commit 7fcb9c3636)
