Fix #25897
Fix #30322#29464 cannot handle some complex `if` conditions correctly because it
only checks `always()` literally. In fact, it's not easy to evaluate the
`if` condition on the Gitea side because evaluating it requires a series
of contexts. But act_runner is able to evaluate the `if` condition
before running the job (for more information, see
[`gitea/act`](517d11c671/pkg/runner/run_context.go (L739-L753)))
. So we can use act_runner to check the `if` condition.
In this PR, how to handle a blocked job depends on its `needs` and `if`:
- If not all jobs in `needs` completed successfully and the job's `if`
is empty, set the job status to `StatusSkipped`
- In other cases, the job status will be set to `StatusWaiting`, and
then act_runner will check the `if` condition and run the job if the
condition is met
(cherry picked from commit 31a0c4dfb4156a7b4d856cceae1e61c7fc1a4a1b)
When performing migrations, and need to remap external users to local
ones, when no local mapping is possible, map the external user to Ghost,
rather than the user who initiated the migration.
Mapping the external user to the migration initiator has the potential
of breaking assumptions elsewhere, like only having one review per pull
request per user. Mapping these migrated, locally unavailable users to
Ghost makes sure these - often hidden - assumptions do not break.
Fixes #3860.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Following gitea#28981, set `X-Forgejo-Sender` and `X-Forgejo-Recipient`
to the username of the respective users, rather than their display name.
The username is more appropriate for these headers, for filtering
purposes. The display name is already included in the From header.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
Replace #25741
Close #24445
Close #30658
Close #20646
~Depends on #30805~
Since #25741 has been rewritten totally, to make the contribution
easier, I will continue the work in this PR. Thanks @6543
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
(cherry picked from commit c6cf96d31d80ab79d370a6192fd761b4443daec2)
Conflicts:
tests/integration/editor_test.go
trivial context conflict because of 75ce1e2ac1 [GITEA] Allow user to select email for file operations in Web UI
tests/integration/pull_merge_test.go
trivial context conflicts in imports because more tests were added in Forgejo
Remove "EncodeSha1", it shouldn't be used as a general purpose hasher
(just like we have removed "EncodeMD5" in #28622)
Rewrite the "time-limited code" related code and write better tests, the
old code doesn't seem quite right.
(cherry picked from commit fb1ad920b769799aa1287441289d15477d9878c5)
Conflicts:
modules/git/utils_test.go
trivial context conflict because sha256 testing in Forgejo has diverged
When creating a repo, the "FORCE_PRIVATE" config option should be
respected, `readonly` doesn't work for checkbox, so it should use
`disabled` attribute.
(cherry picked from commit edbf74c418061b013a5855f604dd6be6baf34132)
Conflicts:
templates/repo/create.tmpl
templates/repo/migrate/codebase.tmpl
templates/repo/migrate/git.tmpl
templates/repo/migrate/gitbucket.tmpl
templates/repo/migrate/gitea.tmpl
templates/repo/migrate/github.tmpl
templates/repo/migrate/gitlab.tmpl
templates/repo/migrate/gogs.tmpl
templates/repo/migrate/onedev.tmpl
already in forgejo fc0c5e80da Fix and improve repo visibility checkbox when FORCE_PRIVATE is on (#3786)
enforcing FORCE_PRIVATE on repo settings was manually tested
with a repository of an unprivileged user after setting
FORCE_PRIVATE = true
PR will finalize the ability to receive a federated star from a remote instance.
This is part of: https://codeberg.org/forgejo/forgejo/pulls/1680
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3871
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
Co-committed-by: Michael Jerger <michael.jerger@meissa-gmbh.de>
There is no activities_model.Action* when sending a review comment,
this is deadcode and should be removed. Or a new event should be added
to differentiate it from a regular comment when evaluating templates.
One part of https://codeberg.org/forgejo/forgejo/pulls/3316, though it may have a little more files touched because I re-created the changes.
> Removed HTML `<title>` part in `<head>` that was present inconsistently in these emails. It doesn't appear to be used by other websites. After all, these are emails, not webpages.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3810
Reviewed-by: Otto <otto@codeberg.org>
replace reply with forgejos forked version
If plain text is selected as the message format in e.g. Apple Mail, the inline attachments are no longer at the end of the mail, but instead directly where they are in the mail. When parsing the mail, these inline attachments are replaced by "--". The new reply version no longer cuts the text at the first "--".
Tests for this are present in reply (7dc5750c6d).
Fixes https://codeberg.org/forgejo/forgejo/issues/3496#issuecomment-1798416
---
Additionally, I reduced the allocations for the inline attachments.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3747
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Beowulf <beowulf@beocode.eu>
Co-committed-by: Beowulf <beowulf@beocode.eu>
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
Fix #30521
we should sync branches first, then detect default branch, or
`git_model.FindBranchNames` will always return empty list, and the
detection will be wrong.
(cherry picked from commit e94723f2de7d9bf12d870f5ce9ffb291a99ba090)
Conflicts:
services/repository/adopt.go
trivial conflict because
e80466f734 Resolve lint for unused parameter and unnecessary type arguments (#30750)
was not cherry-picked
https://github.com/go-gitea/gitea/pull/25812#issuecomment-2099833692
Follow #30573
(cherry picked from commit f7d2f695a4c57b245830a526e77fa62e99e00254)
Conflicts:
services/pull/check.go
trivial conflict because
9b2536b78fdcd3cf444a2f54857d9871e153858f Update misspell to 0.5.1 and add `misspellings.csv` (#30573)
was not cherry-picked
More about codespell: https://github.com/codespell-project/codespell .
I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.
```
❯ grep lint-spell Makefile
@echo " - lint-spell lint spelling"
@echo " - lint-spell-fix lint spelling and fix issues"
lint: lint-frontend lint-backend lint-spell
lint-fix: lint-frontend-fix lint-backend-fix lint-spell-fix
.PHONY: lint-spell
lint-spell: lint-codespell
.PHONY: lint-spell-fix
lint-spell-fix: lint-codespell-fix
❯ git grep lint- -- .forgejo/
.forgejo/workflows/testing.yml: - run: make --always-make -j$(nproc) lint-backend checks-backend # ensure the "go-licenses" make target runs
.forgejo/workflows/testing.yml: - run: make lint-frontend
```
so how would you like me to invoke `lint-codespell` on CI? (without that would be IMHO very suboptimal and let typos sneak in)
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/3270
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Yaroslav Halchenko <debian@onerussian.com>
Co-committed-by: Yaroslav Halchenko <debian@onerussian.com>