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
`KeyID` is never set.
(cherry picked from commit 155269fa586c41a268530c3bb56349e68e6761d7)
Conflicts:
models/user/email_address.go
trivial context conflict
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>
- When previewing the content in a review, no font size was set. This
resulted in the previewed content being bigger than other text and
therefor creating an noticable inconsistency.
- Set the font size of the previewed content, 14px, this is consistent
with how the content would be rendered.
- `comment-code-cloud` is the class used for the review boxes.
`.ui.tab.markup` means it only applies to the preview tab.
RequestReview get deleted on review.
So we don't have to try to load them on comments.
broken out #28544
(cherry picked from commit 6fad2c874438275d3f69bb1cc223708bd2d27ff6)
- Update all excluding `@mcaptcha/vanilla-glue` and
`eslint-plugin-array-func`
- Remove deprecated and duplicate eslint rule
- Tested Monaco, Mermaid and Swagger
(cherry picked from commit 4fe37124e9ad5395b734662a7e8ab7b0025c38a3)
If no `-o description=` is provided, fill it in automatically from the
first commit, just like title. Also allow filling in either, and
specifying them independently.
This means that `git push origin HEAD:refs/for/main/my-local-branch`
will fill in the PR title, *and* the description, without having to
specify additional parameters.
The description is the first commit's message without the first two
lines (the title and a newline, as customary).
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
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
Use `ctx.ServerError` instead of a separate `log.Error` + `ctx.Error`.
`ctx.ServerError` does essentially the same thing, but better.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
If a repository administrator is viewing a repository, and there are
units that can be enabled, display an "Add more..." link that leads to
the repository unit settings page.
The goal here is to allow instances to configure a small set of repo
units to be enabled by default, but also highlight for repo admins that
they can add more.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
This splits out the repository unit settings (formerly "Advanced
settings" under the repository settings page) into their own, separate
page.
The primary reason for this is that the settings page became long and
complicated, with a structure that not always made sense. A secondary
reason is that toggling units on and off should not necessarily be an
"advanced" setting. We want to make doing that easier, and having the
units on their own page helps with that.
This is basically a refactor, there is no new functionality introduced,
just an extra pair of routes for the new page, and the supporting code.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
- In Git version v2.43.1, the behavior of `GIT_FLUSH` was accidentially
flipped. This causes Forgejo to hang on the `check-attr` command,
because no output was being flushed.
- Workaround this by detecting if Git v2.43.1 is used and set
`GIT_FLUSH=0` thus getting the correct behavior.
- Ref: https://lore.kernel.org/git/CABn0oJvg3M_kBW-u=j3QhKnO=6QOzk-YFTgonYw_UvFS1NTX4g@mail.gmail.com/
- Resolves #2333.
- I found this while doing some unrelated testing in Forgejo. It wasn't
my intention to log failed SQL queries if they were cancelled (which can
happen quite frequently for larger instances) as in those cases it's not
interesting to know which SQL query was run. My intentation was only to
log an SQL query if there was an error reported by the database.
- Ref #2140
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>
Forgejo now has its own lifecycle and its version is derived from the
tag. The Gitea tags are no longer found in the Forgejo codebase and
can no longer be used for that purpose.
When a Forgejo release is published, for interoperability with the
existing tools in the ecosystem, it advertises the supported Gitea
version via /api/v1/version. It is set in the Makefile manually and
cannot be automatically set.
https://codeberg.org/forgejo-contrib/delightful-forgejo#packaging
Existing Forgejo packages rely on the Makefile to build and the change
must be done in a way that tries to not break their assumptions. From
the point of view of a Forgejo package build, the following will
happen on the next major release:
- The package version will bump from v1.21.x to v7.0.0
- /api/v1/version will bump from v1.21.x to v1.22.0
- /api/forgejo/v1/version will bump from v6.x to v7.0.0
The Makefile uses the following variables:
GITEA_VERSION is returned by /api/v1/version
FORGEJO_VERSION is returned by /api/forgejo/v1/version
VERSION is used in the name the binary file and the source archive
Before:
GITEA_VERSION is the computed version
FORGEJO_VERSION is set manually
VERSION defaults to GITEA_VERSION
After:
FORGEJO_VERSION is the computed version
GITEA_VERSION is set manually
VERSION defaults to FORGEJO_VERSION
When the version is computed, it comes from:
- The content of the VERSION file if it exists. It is inserted in
the source archive because it does not contain a git repository
- Otherwise the output of `git describe`
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>
Commit 360b3fd17c (Include username in email headers (#28981),
2024-02-03) adds usernames to the From field of notification emails in
the form of `Display Name (@username)`, to prevent spoofing. However,
some email filtering software flags "@" in the display name part of the
From field as potential spoofing, as you could set the display name part
to another email address than the one you are sending from (e.g.
`From: "apparent@email-address" <actual@email-address>`). To avoid
being flagged, instead send emails from `Display Name (username)`.
Closes: #29107
---------
Co-authored-by: Giteabot <teabot@gitea.io>
(cherry picked from commit 5b2fd0fc19a2a77414c8e2989b4794b6617221f5)
- Use maintained fork https://github.com/golangci/misspell
- Rename `mispell-check` to `lint-spell`, add `lint-spell-fix`
- Run `lint-spell` in separate actions step
- Lint more files, fix discovered issues
- Remove inaccurate and outdated info in docs (we do not need GOPATH for
tools anymore)
Maybe later we can add more spellchecking tools, but I have not found
any good ones yet.
(cherry picked from commit 9c39f8515fa88d644736c6773d7a05d070a02e82)
Conflicts:
.github/workflows/pull-compliance.yml
Makefile
Replace #28849. Thanks to @yp05327 for the looking into the problem.
Fix #28840
The old behavior of newSignatureFromCommitline is not right. The new
parseSignatureFromCommitLine:
1. never fails
2. only accept one format (if there is any other, it could be easily added)
And add some tests.
(cherry picked from commit a24e1da7e9e38fc5f5c84c083d122c0cc3da4b74)
