Outgoing new release e-mail notifications were missing links to the
actual release. An example from Codeberg.org e-mail:
<a href=3D"">View it on Codeberg.org</a>.<br/>
This PR adds `"Link"` context property pointing to the release on the
web interface.
The change was tested using `[mailer] PROTOCOL=dummy`.
Signed-off-by: Wiktor Kwapisiewicz <wiktor@metacode.biz>
(cherry picked from commit 37191dcfbdbd007266a4d15a3c85cdf94cec1a7a)
When setting `url.host` on a URL object with no port specified (like is
the case of default port), the resulting URL's port will not change.
Workaround this quirk in the URL standard by explicitely setting port
for the http and https protocols.
Extracted the logic to a function for the purpose of testing. Initially
I wanted to have the function in utils.js, but it turns out esbuild can
not treeshake the unused functions which would result in the
webcomponents chunk having all 2kB utils.js inlined, so it seemed not
worth.
Fixes: https://github.com/go-gitea/gitea/issues/29084
(cherry picked from commit b6bf8041d8e8ee845728687b1f358f1d482afff2)
Fix for gitea putting everything into one request without batching and
sending it to Elasticsearch for indexing as issued in #28117
This issue occured in large repositories while Gitea tries to
index the code using ElasticSearch.
I've applied necessary changes that takes batch length from below config
(app.ini)
```
[queue.code_indexer]
BATCH_LENGTH=<length_int>
```
and batches all requests to Elasticsearch in chunks as configured in the
above config
(cherry picked from commit 5c0fc9087211f01375f208d679a1e6de0685320c)
Remove lightningcss and minify with esbuild again. The size of output
CSS will increase by around 1.4%, but I think it's worth it to allow
building gitea in more cases like the one in the linked issue. We can
reconsider once lightningcss becomes more stable.
Fixes: https://github.com/go-gitea/gitea/issues/29058
(cherry picked from commit 5849d4fde347cd1e47f2243b3239724c73b1261d)
This adds a few tests for the previous change, to verify that issue
template configs, issue templates and pr templates are all recognized in
`.forgejo` directories.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
When issue templates were moved into services in
def4956122, the code was also refactored
and simplified. Unfortunately, that simplification broke the
`/api/v1/{owner}/{repo}/issue_templates` route, because it was
previously using a helper function that ignored invalid templates, and
after the refactor, the function it called *always* returned non-nil as
the second return value. This, in turn, results in the aforementioned
end point always returning an internal server error.
This change restores the previous behaviour of ignoring invalid files
returned by `issue.GetTemplatesFromDefaultBranch`, and adds a few test
cases to exercise the endpoint.
Other users of `GetTemplatesFromDefaultBranch` already ignore the second
return value, or handle it correctly, so no changes are necessary there.
Signed-off-by: Gergely Nagy <forgejo@gergo.csillger.hu>
* Split TestPullRequest out of AddTestPullRequestTask
* Before scheduling the task, AddTestPullRequestTask stores the max
index of the repository
* When the task runs, it does not take into account pull requests that
have an index higher than the recorded max index
When AddTestPullRequestTask is called with isSync == true, it is the
direct consequence of a new commit being pushed. Forgejo knows nothing
of this new commit yet. If a PR is created later and its head
references the new commit, it will have an index that is higher and
must not be taken into account. It would be acting and triggering a
notification for a PR based on an event that happened before it
existed.
Refs: https://codeberg.org/forgejo/forgejo/issues/2009
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/2236
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
(cherry picked from commit b3be895a30)
