# 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
![demo](https://github.com/go-gitea/gitea/assets/20454870/585cd6e8-f329-4c9e-ab53-a540acbd7988)
---------
Signed-off-by: Yarden Shoham <git@yardenshoham.com>
Co-authored-by: silverwind <me@silverwind.io>
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>
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="https://github.com/go-gitea/gitea/assets/81045/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.
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="https://github.com/go-gitea/gitea/assets/9418365/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>
This PR made the code simpler, reduced unnecessary database queries and
fixed some warnning for the errors.New .
---------
Co-authored-by: KN4CK3R <admin@oldschoolhack.me>
Also resolves a warning for current releases
```
| ##[group]GitHub Actions runtime token ACs
| ##[warning]Cannot parse GitHub Actions Runtime Token ACs: "undefined" is not valid JSON
| ##[endgroup]
====>
| ##[group]GitHub Actions runtime token ACs
| ##[endgroup]
```
\* this is an error in v3
References in the docker org:
-
831ca179d3/src/main.ts (L24)
-
7d8b4dc669/src/github.ts (L61)
No known official action of GitHub makes use of this claim.
Current releases throw an error when configure to use actions cache
```
| ERROR: failed to solve: failed to configure gha cache exporter: invalid token without access controls
| ##[error]buildx failed with: ERROR: failed to solve: failed to configure gha cache exporter: invalid token without access controls
```
Tested a few things, all working fine. Not sure if the chinese machine
translation is good.
---------
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Tailwind content is not going to appear in `web_src/css`,
`web_src/fomantic` or `web_src/svg` or the JSON templates, so we don't
need to have tailwind scan these directories which will speed up the
build.
---------
Co-authored-by: delvh <dev.lh@web.de>
Follow #29418
I think using "flex-wrap: wrap" here is better than hard-coding the screen width.
By using "flex-wrap: wrap", the UI layouts automatically for various
widths (even if in some languages, the sentence might be pretty long)
Fix for regressions introduced by #28805
Enabled projects on repos created before the PR weren't detected. Also,
the way projects mode was detected in settings didn't match the way it
was detected on permission check, which leads to confusion.
Co-authored-by: Giteabot <teabot@gitea.io>
1. Make fomantic build use [our
browserslist](e3524c63d6/package.json (L99)).
I found no other way than to sed-replace into it's js, the normal
browserlist config files do not work. The effect of this change is the
removal of some uneeded CSS vendor prefixes.
2. Regenerate `web_src/fomantic/package-lock.json`, this might shut up
some security scanners.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
Some contributors may be surprised when moving the feature PRs to the
next release when the feature freeze time comes. So this PR documents
the habits we have done for feature freeze so people expect the
maintainers' behaviors. We are sorry for disturbing you with the
milestones changes.
A feature freeze announcement should be published 2 or 3 weeks before
the feature freeze by maintainers.
* "mail/issue/default.tmpl": the body is rendered by backend
`markdown.RenderString() HTML`, it has been already sanitized
* "repo/settings/webhook/base_list.tmpl": "Description" is prepared by
backend `ctx.Tr`, it doesn't need to be sanitized
Part of #23318
Add menu in repo settings to allow for repo admin to decide not just if
projects are enabled or disabled per repo, but also which kind of
projects (repo-level/owner-level) are enabled. If repo projects
disabled, don't show the projects tab.
![grafik](https://github.com/go-gitea/gitea/assets/47871822/b9b43fb4-824b-47f9-b8e2-12004313647c)
---------
Co-authored-by: delvh <dev.lh@web.de>
Add new option:
`visible`: witch can hide a specific field of the form or the created
content afterwards
It is a string array witch can contain `form` and `content`. If only
`form` is present, it wont show up in the created issue afterwards and
the other way around. By default it sets both except for markdown
As they are optional and github don't have any similar thing, it is non
breaking and also do not conflict with it.
With this you can:
- define "post issue creation" elements like a TODO list to track an
issue state
- make sure to have a checkbox that reminds the user to check for a
thing but dont have it in the created issue afterwards
- define markdown for the created issue (was the downside of using yaml
instead of md in the past)
- ...
## Demo
```yaml
name: New Contribution
description: External Contributor creating a pull
body:
- type: checkboxes
id: extern-todo
visible: [form]
attributes:
label: Contribution Guidelines
options:
- label: I checked there exist no similar feature to be extended
required: true
- label: I did read the CONTRIBUTION.MD
required: true
- type: checkboxes
id: intern-todo
visible: [content]
attributes:
label: Maintainer Check-List
options:
- label: Does this pull follow the KISS principe
- label: Checked if internal bord was notifyed
# ....
```
[Demo
Video](https://cloud.obermui.de/s/tm34fSAbJp9qw9z/download/vid-20240220-152751.mkv)
---
*Sponsored by Kithara Software GmbH*
---------
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>