The user that caused the notification to re-evaluates the
schedules is not the one that will trigger the workflows. They are
background tasks that are authored by the action user (id -2).
Such a mis-assignment is problematic when the user that caused the
notification is deleted.
Fixes: https://codeberg.org/forgejo/forgejo/issues/3211
(cherry picked from commit c3e2c25359)
backport #29962
This PR fixed a bug when the user switching pages too fast, he will
logout automatically.
The reason is that when the error is context cancelled, the previous
code think user hasn't login then the session will be deleted. Now it
will return the errors but not think it's not login.
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit c03b1e28544ee60c72f9dc7d9f362753bb3d778c)
- `user_model.DeleteInactiveEmailAddresses` related code was added in
Gogs as part to delete inactive users, however since then the related
code to delete users has changed and this code now already delete email
addresses of the user, it's therefore not needed anymore to
`DeleteInactiveEmailAddresses`.
- The call to `DeleteInactiveEmailAddresses` can actually cause issues.
As the associated user might not have been deleted, because it
was not older than the specified `olderThan` argument. Therefore causing
a database inconsistency and lead to internal server errors if the user
tries to activate their account.
- Adds unit test to verify correct behavior (fails without this patch).
Backport #29672 by @charles7668
Close#29661fix#29656
Co-authored-by: charles <30816317+charles7668@users.noreply.github.com>
(cherry picked from commit 1f897637441a9a5c43e01b84e374d836d9260a00)
Backport #29531 by wxiaoguang
Add two "HTMLURL" methods for PackageDescriptor.
And rename "FullWebLink" to "VersionWebLink"
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit 8723389028bcb5e96359fca61efd7d6da0d6af99)
Backport #29464 by @Zettat123
Fix#27906
According to GitHub's
[documentation](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds),
a job should always run when its `if` is `always()`
> If you would like a job to run even if a job it is dependent on did
not succeed, use the `always()` conditional expression in
`jobs.<job_id>.if`.
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit eabcfd3f7d9321fcf03e52977c178a96627a68da)
Backport #29342 by @Zettat123
Fix#29249
~~Use the `/repos/{owner}/{repo}/archive/{archive}` API to download.~~
Apply #26430 to archive download URLs.
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit 829b807a91f9895e3f4b262f688a8d0d9a44caf6)
Fixes#28945
Backport #28948
Setting the avatar is wrong and creating a random password is equal to
leave it empty.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 7ea2ffaf166780b7786291f7ff022e3f5b49e8c2)
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>
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>
(cherry picked from commit 7b4dba3aa0)
Conflicts:
services/actions/notifier_helper.go
tests/integration/actions_trigger_test.go
trivial context conficts
services/actions/main_test.go is different in v1.21
- If the APKINFO contains an install if condition, write it in the APKINDEX.
- No integration testing, as I don't have the files to regenerate the
hardcoded compressed(?) APKINFO in the test.
- Resolves#2174
(cherry picked from commit 11da776bef)
(cherry picked from commit 2824ae4cf2)
Backport #28920 by @Zettat123
Fixes#28699
This PR implements the `MigrateRepository` method for `actionsNotifier`
to detect the schedules from the workflow files in the migrated
repository.
Co-authored-by: Zettat123 <zettat123@gmail.com>
(cherry picked from commit 55c53080d1)
Backport #28886 by @KN4CK3R
The method can't be called with an outer transaction because if the user
is not a collaborator the outer transaction will be rolled back even if
the inner transaction uses the no-error path.
`has == 0` leads to `return nil` which cancels the transaction. A
standalone call of this method does nothing but if used with an outer
transaction, that will be canceled.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit fd1edb9d9d)
Backport https://github.com/go-gitea/gitea/pull/28794Fixes#22236
---
Error occurring currently while trying to revert commit using read-tree
-m approach:
> 2022/12/26 16:04:43 ...rvices/pull/patch.go:240:AttemptThreeWayMerge()
[E] [63a9c61a] Unable to run read-tree -m! Error: exit status 128 -
fatal: this operation must be run in a work tree
> - fatal: this operation must be run in a work tree
We need to clone a non-bare repository for `git read-tree -m` to work.
bb371aee6e
adds support to create a non-bare cloned temporary upload repository.
After cloning a non-bare temporary upload repository, we [set default
index](https://github.com/go-gitea/gitea/blob/main/services/repository/files/cherry_pick.go#L37)
(`git read-tree HEAD`).
This operation ends up resetting the git index file (see investigation
details below), due to which, we need to call `git update-index
--refresh` afterward.
Here's the diff of the index file before and after we execute
SetDefaultIndex: https://www.diffchecker.com/hyOP3eJy/
Notice the **ctime**, **mtime** are set to 0 after SetDefaultIndex.
You can reproduce the same behavior using these steps:
```bash
$ git clone https://try.gitea.io/me-heer/test.git -s -b main
$ cd test
$ git read-tree HEAD
$ git read-tree -m 1f085d7ed8 1f085d7ed8 9933caed00
error: Entry '1' not uptodate. Cannot merge.
```
After which, we can fix like this:
```bash
$ git update-index --refresh
$ git read-tree -m 1f085d7ed8 1f085d7ed8 9933caed00
```
(cherry picked from commit 62f2d717b7)
Backport #26745Fixes#26548
This PR refactors the rendering of markup links. The old code uses
`strings.Replace` to change some urls while the new code uses more
context to decide which link should be generated.
The added tests should ensure the same output for the old and new
behaviour (besides the bug).
We may need to refactor the rendering a bit more to make it clear how
the different helper methods render the input string. There are lots of
options (resolve links / images / mentions / git hashes / emojis / ...)
but you don't really know what helper uses which options. For example,
we currently support images in the user description which should not be
allowed I think:
<details>
<summary>Profile</summary>
https://try.gitea.io/KN4CK3R
</details>
(cherry picked from commit 022552d5b6)
Backport #28426 by @KN4CK3R
Fixes#28420
Don't return `nil` if the input was empty.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 95901a99c0)
Backport #28731 by @earl-warren
- If there's a error with the Git command in `checkIfPRContentChanged`
the stderr wasn't concatendated to the error, which results in still not
knowing why an error happend.
- Adds concatenation for stderr to the returned error.
- Ref: https://codeberg.org/forgejo/forgejo/issues/2077
Co-authored-by: Earl Warren <109468362+earl-warren@users.noreply.github.com>
Co-authored-by: Gusted <postmaster@gusted.xyz>
(cherry picked from commit bce27d0a31)
Backport #28638 by @lng2020
I noticed the `BuildAllRepositoryFiles` function under the Alpine folder
is unused and I thought it was a bug.
But I'm not sure about this. Was it on purpose?
Co-authored-by: Nanguan Lin <70063547+lng2020@users.noreply.github.com>
(cherry picked from commit 3e1bd61000)
- The current architecture is inherently insecure, because you can
construct the 'secret' cookie value with values that are available in
the database. Thus provides zero protection when a database is
dumped/leaked.
- This patch implements a new architecture that's inspired from: [Paragonie Initiative](https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#secure-remember-me-cookies).
- Integration testing is added to ensure the new mechanism works.
- Removes a setting, because it's not used anymore.
(cherry picked from commit eff097448b)
[GITEA] rework long-term authentication (squash) add migration
Reminder: the migration is run via integration tests as explained
in the commit "[DB] run all Forgejo migrations in integration tests"
(cherry picked from commit 4accf7443c)
(cherry picked from commit 99d06e344ebc3b50bafb2ac4473dd95f057d1ddc)
(cherry picked from commit d8bc98a8f0)
(cherry picked from commit 6404845df9)
(cherry picked from commit 72bdd4f3b9)
(cherry picked from commit 4b01bb0ce8)
(cherry picked from commit c26ac31816)
(cherry picked from commit 8d2dab94a6)
Conflicts:
routers/web/auth/auth.go
https://codeberg.org/forgejo/forgejo/issues/2158
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>
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>
- Add condition to ensure doer isn't nil when using it.
- Added unit test.
- Resolves#2055
(cherry picked from commit 32967b2b5a62f7c7adc270aa3e6b123406b7b6d0)
The cancelation of jobs is taken care of by handleWorkflows which is
called right after handleSchedules with the same event.
(cherry picked from commit ad1af2e436)
do not reuse the payload of the event that triggered the creation of
the scheduled event. Create a new one instead that contains no other
information than the event name in the action field ("schedule").
(cherry picked from commit 0b40ca1ea5)
handleSchedules() is called every time an event is received and will
check the content of the main branch to (re)create scheduled events.
There is no reason why intput.Event will be relevant when the schedule
workflow runs.
(cherry picked from commit 9a712bb276)
Backport #28454 (the only conflict is caused by some comments)
* Close#24483
* Close#28123
* Close#23682
* Close#23149
(cherry picked from commit a3f403f438)
Conflicts:
modules/setting/ui.go
trivial context conflict
Backport #28428 by @KN4CK3R
There could be a nil pointer exception if the file is not found because
that specific error is suppressed but not handled.
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
(cherry picked from commit 97a0bf151a)
- The transaction in combination with Git push was causing deadlocks if
you had the `push_update` queue set to `immediate`. This was the root
cause of slow integration tests in CI.
- Remove the sync branch code as this is already being done in the Git
post-receive hook.
- Add tests to proof the branch models are in sync even with this code
removed.
Backport of https://codeberg.org/forgejo/forgejo/pulls/1962
(cherry picked from commit a064065cb9)
This reverts commit 172fdd0d32.
This code was introduced for a test case that is no longer in use. It
should guard against the provider being null but that's not worth the
effort for deadcode. Just remove it.
Refs: https://codeberg.org/forgejo/forgejo/issues/1984
It shows warnings although the setting is not set, this will surely be
fixed later but there is no sense in spaming the users right now. This
revert can be discarded when another fix lands in v1.21.
su -c "forgejo admin user generate-access-token -u root --raw --scopes 'all,sudo'" git
2023/12/12 15:54:45 .../setting/security.go:166:loadSecurityFrom() [W] Enabling Query API Auth tokens is not recommended. DISABLE_QUERY_AUTH_TOKEN will default to true in gitea 1.23 and will be removed in gitea 1.24.
This reverts commit 0e3a5abb69.
Conflicts:
routers/api/v1/api.go
Backport #28390 by @jackHay22
## Changes
- Add deprecation warning to `Token` and `AccessToken` authentication
methods in swagger.
- Add deprecation warning header to API response. Example:
```
HTTP/1.1 200 OK
...
Warning: token and access_token API authentication is deprecated
...
```
- Add setting `DISABLE_QUERY_AUTH_TOKEN` to reject query string auth
tokens entirely. Default is `false`
## Next steps
- `DISABLE_QUERY_AUTH_TOKEN` should be true in a subsequent release and
the methods should be removed in swagger
- `DISABLE_QUERY_AUTH_TOKEN` should be removed and the implementation of
the auth methods in question should be removed
## Open questions
- Should there be further changes to the swagger documentation?
Deprecation is not yet supported for security definitions (coming in
[OpenAPI Spec version
3.2.0](https://github.com/OAI/OpenAPI-Specification/issues/2506))
- Should the API router logger sanitize urls that use `token` or
`access_token`? (This is obviously an insufficient solution on its own)
Co-authored-by: Jack Hay <jack@allspice.io>
Co-authored-by: delvh <dev.lh@web.de>
(cherry picked from commit f144521aea)
Fix#28056
Backport #28361
This PR will check whether the repo has zero branch when pushing a
branch. If that, it means this repository hasn't been synced.
The reason caused that is after user upgrade from v1.20 -> v1.21, he
just push branches without visit the repository user interface. Because
all repositories routers will check whether a branches sync is necessary
but push has not such check.
For every repository, it has two states, synced or not synced. If there
is zero branch for a repository, then it will be assumed as non-sync
state. Otherwise, it's synced state. So if we think it's synced, we just
need to update branch/insert new branch. Otherwise do a full sync. So
that, for every push, there will be almost no extra load added. It's
high performance than yours.
For the implementation, we in fact will try to update the branch first,
if updated success with affect records > 0, then all are done. Because
that means the branch has been in the database. If no record is
affected, that means the branch does not exist in database. So there are
two possibilities. One is this is a new branch, then we just need to
insert the record. Another is the branches haven't been synced, then we
need to sync all the branches into database.
(cherry picked from commit 87db4a47c8)
