Fix#28735
GitHub render `\```math\``` ` as a block now.
Add `display` class will render it as a block.
After:
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
- Removed all jQuery AJAX calls and replaced with our fetch wrapper
- Tested the comment edit history list, diff, and delete functionality
and it works as before
# Demo using `fetch` instead of jQuery AJAX
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
The internal links to other files in the repository were not rendering
with the Src Prefix (/src/branch-name/file-path). This commit fixes that
by using the `SrcLink` as base if available.
Resolves#29668
Previously it was only partially styled, e.g. there was black text on
white background even in dark theme caused by fomantic styles.
<img width="195" alt="image"
src="bc5cf516-2aef-45c3-854a-c9f5497aacca">
<img width="195" alt="Screenshot 2024-03-09 at 02 09 29"
src="ef0af17d-6e0b-402e-b24d-bfa34dc2f4e0">
Co-authored-by: Giteabot <teabot@gitea.io>
We need to scan `.go` files for tailwind classes. Does not seem to
affect build time much luckily.
Fixes:
https://github.com/go-gitea/gitea/pull/29678#discussion_r1518448600
Verified via `rg tw-object-contain public/assets/css/index.css`.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Support pasting URLs over selection text in the textarea editor. Does
not work in EasyMDE and I don't intend to support it. Image paste works
as usual in both Textarea and EasyMDE.
The new `replaceTextareaSelection` function changes textarea content via
[`insertText`](https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#using_inserttext)
command, which preserves history, e.g. `CTRL-Z` works and is also
demostrated below. We should later refactor the image paste code to use
the same function because it currently destroys history.
Overriding the formatting via `Shift` key is supported as well, e.g.
`Ctrl+Shift+V` will insert the URL as-is, like on GitHub.
The default version is 3.9.2, which is not supported by poetry.
---------
Co-authored-by: silverwind <me@silverwind.io>
The branch page for blender project will take 6s because calculating
divergence is very slow.
This PR will add a cache for the branch divergence calculation. So when
the second visit the branch list, it will take only less 200ms.
This seeks to fix the bug reported on issue #29196.
Cause:
ID's with custom characters (- , _ , etc.), were not linking correctly
in the Markdown file when rendered in the browser because the ID in the
respective destinies would be different than the one in anchor, while
for IDs with only letters, the ID would be the same.
Fix:
It was suggested that to fix this bug, it should more or less like
GitHub does it. While in gitea the anchors would be put in HTML like
this:
```
<p dir="auto"><a href="#user-content-_toc152597800" rel="nofollow">Review</a></p>
<p dir="auto"><a href="#user-content-_toc152597802" rel="nofollow">Staging</a></p>
<p dir="auto"><a href="#user-content-_toc152597803" rel="nofollow">Development</a></p>
<p dir="auto"><a href="#user-content-_toc152597828" rel="nofollow">Testing</a></p>
<p dir="auto"><a href="#user-content-_toc152597829" rel="nofollow">Unit-tests</a></p>
```
In GitHub, the same anchor's href properties would be the same without
"user-content-" trailing behind.
So my code made sure to change those anchors, so it would not include
"user-content-" and then add respective Event Listeners so it would
scroll into the supposed places.
Fixes: #29196
---------
Co-authored-by: silverwind <me@silverwind.io>
Fomantic grey labels in the dashboard repo lists were showing original
fomantic colors, fixed that. Also slightly tweaked the light theme
colors so it uses same opacity values as dark theme.
<img width="165" alt="Screenshot 2024-03-07 at 21 06 23"
src="72744d6f-2ee1-4e5d-8ba0-b482a446f535">
<img width="167" alt="Screenshot 2024-03-07 at 21 06 00"
src="1ba93775-e5a9-4b28-b90f-59c1e9199687">
- Follows https://github.com/go-gitea/gitea/pull/29121
When I implemented alert blocks I was always testing the markdown in
issue comments. I used `<br />` for line breaks and it looked good. I
have since learned that the markdown on README files doesn't allow these
tags. So a comment with
```md
> [!NOTE]
> If you're interested in using our APIs, we have experimental support with [documentation](https://try.gitea.io/api/swagger).
```
looked like this in a comment
but looked like this in a README
So I changed how we render the alert block by having the alert itself
have a dedicated paragraph, so line breaks happen naturally between
paragraphs.
# Before
# After
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
Fixes: https://github.com/go-gitea/gitea/issues/28371
Fixed by using a JS solution that formats according to `lang`, but alters the 24h format setting as per user's locale. This will work for all tooltips:
<img width="243" alt="Screenshot 2024-03-07 at 23 03 35" src="6d16c71c-6786-4eda-8cdc-50ec68ba62c6">
<img width="250" alt="Screenshot 2024-03-07 at 23 03 17" src="4e26bbb7-12df-4b81-bd37-14705e87e8f7">
<img width="310" alt="Screenshot 2024-03-07 at 23 14 34" src="1ef599f0-6401-4e19-b1da-59cdfc09b0f6">
I think there is only one other place in the UI where we render such absolute dates, which is in the actions view and which I've also fixed:
<img width="275" alt="Screenshot 2024-03-07 at 23 04 00" src="df0fbe1f-96ee-4338-ab5e-2b10e215005d">
Refactor the webhook logic, to have the type-dependent processing happen
only in one place.
---
## Current webhook flow
1. An event happens
2. It is pre-processed (depending on the webhook type) and its body is
added to a task queue
3. When the task is processed, some more logic (depending on the webhook
type as well) is applied to make an HTTP request
This means that webhook-type dependant logic is needed in step 2 and 3.
This is cumbersome and brittle to maintain.
Updated webhook flow with this PR:
1. An event happens
2. It is stored as-is and added to a task queue
3. When the task is processed, the event is processed (depending on the
webhook type) to make an HTTP request
So the only webhook-type dependent logic happens in one place (step 3)
which should be much more robust.
## Consequences of the refactor
- the raw event must be stored in the hooktask (until now, the
pre-processed body was stored)
- to ensure that previous hooktasks are correctly sent, a
`payload_version` is added (version 1: the body has already been
pre-process / version 2: the body is the raw event)
So future webhook additions will only have to deal with creating an
http.Request based on the raw event (no need to adjust the code in
multiple places, like currently).
Moreover since this processing happens when fetching from the task
queue, it ensures that the queuing of new events (upon a `git push` for
instance) does not get slowed down by a slow webhook.
As a concrete example, the PR #19307 for custom webhooks, should be
substantially smaller:
- no need to change `services/webhook/deliver.go`
- minimal change in `services/webhook/webhook.go` (add the new webhook
to the map)
- no need to change all the individual webhook files (since with this
refactor the `*webhook_model.Webhook` is provided as argument)
The tests on migration tests failed but CI reports successfully
2004468596 (step):8:141
This PR will fix the bug on migration v283 and also the CI hidden
behaviour.
The reason is on the Makefile
`GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags='$(TEST_TAGS)' $(MIGRATE_TEST_PACKAGES)` will
return the error exit code.
But
`for pkg in $(shell $(GO) list
code.gitea.io/gitea/models/migrations/...); do \
GITEA_ROOT="$(CURDIR)" GITEA_CONF=tests/mysql.ini $(GO) test
$(GOTESTFLAGS) -tags '$(TEST_TAGS)' $$pkg; \
done`
will not work.
This also fix#29602
# Preview Tab
- Removed the jQuery AJAX call and replaced with our fetch wrapper
- Tested the preview tab functionality and it works as before
# Diff Tab
- Removed the jQuery AJAX call and replaced with htmx
- Tested the diff tab functionality and it works as before
## htmx Attributes
- `hx-post="{{.RepoLink}}..."`: make a POST request to the endpoint
- `hx-indicator=".tab[data-tab='diff']"`: attach the loading indicator
to the tab body
- `hx-target=".tab[data-tab='diff']"`: target the tab body for swapping
with the response
- `hx-swap="innerHTML"`: swap the target's inner HTML
- `hx-include="#edit_area"`: include the value of the textarea (content)
in the request body
- `hx-vals='{"context":"{{.BranchLink}}"}'`: include the context in the
request body
- `hx-params="context,content"`: include only these keys in the request
body
# Demo using `fetch` and `htmx` instead of jQuery AJAX
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
1. Checked all logos, updated 3 of them to newer versions.
2. Remove `open-with-` infix on the editor logos to be consistent with
other files.
<img width="626" alt="image"
src="3b2d9486-6e0a-45c6-b0e4-d38dc4c0b118">
- Increase contrast overall
- Unalias the ansi color in dark theme and copy them to light
- Add outer border
- Add border radius
<img width="1337" alt="Screenshot 2024-03-06 at 22 30 03"
src="11407c0f-0bb2-435e-a034-22b1f106d9b0">
<img width="1335" alt="Screenshot 2024-03-06 at 22 36 59"
src="267db442-0979-4acc-a79e-8579b4cb0262">
Consider executable files as a valid case when returning a DownloadURL for them.
They are just regular files with the difference being the executable permission bit being set.
Co-authored-by: Gusted <postmaster@gusted.xyz>
There are a few inconsistencies within Gitea and this PR addresses one
of them. This PR updates the sign-in page layout, including the register
and openID tabs, to match the layout of the settings pages
(/user/settings) for more consistency.
This PR updates the following routes:
`/user/login`
`/user/sign_up`
`/user/login/openid`
`/user/forgot_password`
`/user/link_account`
`/user/recover_account`
**Before**
<img width="968" alt="Screenshot 2024-02-05 at 8 27 24 AM"
src="fb0cb517-57c0-4eed-be1d-56f36bd1960d">
**After**
<img width="968" alt="Screenshot 2024-02-05 at 8 26 39 AM"
src="428d691d-0a42-4a67-a646-05527f2a7b41">
This PR addresses a revert of the original PR due to this
[comment](https://github.com/go-gitea/gitea/pull/28753#issuecomment-1956596817).
---------
Co-authored-by: rafh <rafaelheard@gmail.com>
After repository commit status has been introduced on dashaboard, the
most top SQL comes from `GetLatestCommitStatusForPairs`.
This PR adds a cache for the repository's default branch's latest
combined commit status. When a new commit status updated, the cache will
be marked as invalid.
<img width="998" alt="image"
src="76759de7-3a83-4d54-8571-278f5422aed3">
There is a fundamental design problem of the "manager" and the "wait
group".
If nothing has started, the "Wait" just panics: sync: WaitGroup is
reused before previous Wait has returned
There is no clear solution besides a complete rewriting of the "manager"
If there are some mistakes in the app.ini, end users would just see the
"panic", but not the real error messages. A real case: #27643
This PR is just a quick fix for the annoying panic problem.
Follow #29248
The project view page still using `user/overview/header.tmpl`
Before:
After:
Detect broken git hooks by checking if the commit id of branches in DB
is the same with the git repo.
It can help #29338#28277 and maybe more issues.
Users could complain about actions, webhooks, and activities not
working, but they were not aware that it is caused by broken git hooks
unless they could see a warning.
<img width="1348" alt="image"
src="2b92a46d-7f1d-4115-bef4-9f970bd695da">
It should be merged after #29493. Otherwise, users could see a ephemeral
warning after committing and opening the repo home page immediately.
And it also waits for #29495, since the doc link (the anchor part) will
be updated.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Giteabot <teabot@gitea.io>
Unlike other async processing in the queue, we should sync branches to
the DB immediately when handling git hook calling. If it fails, users
can see the error message in the output of the git command.
It can avoid potential inconsistency issues, and help #29494.
---------
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Fix#29136
Before: The result is a table and all line numbers are all in one row.
After: Use a separate table column for the line numbers.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
