Add markdownlint (#20512)

Add `markdownlint` linter and fix issues. Config is based on the one
from electron's repo with a few rules relaxed.

.editorconfig

@@ -26,6 +26,3 @@ indent_style = tab
 
 [*.svg]
 insert_final_newline = false
-
-[*.md]
-trim_trailing_whitespace = false

.markdownlint.yaml

@@ -0,0 +1,18 @@
+commands-show-output: false
+fenced-code-language: false
+first-line-h1: false
+header-increment: false
+line-length: {code_blocks: false, tables: false, stern: true, line_length: -1}
+no-alt-text: false
+no-bare-urls: false
+no-blanks-blockquote: false
+no-duplicate-header: {allow_different_nesting: true}
+no-emphasis-as-header: false
+no-empty-links: false
+no-hard-tabs: {code_blocks: false}
+no-inline-html: false
+no-space-in-code: false
+no-space-in-emphasis: false
+no-trailing-punctuation: false
+no-trailing-spaces: {br_spaces: 0}
+single-h1: false

CONTRIBUTING.md

@@ -81,12 +81,12 @@ Here's how to run the test suite:
 |``make lint-frontend`` | lint frontend files |
 |``make lint-backend`` | lint backend files |
 
-- run test code (Suggest run in Linux) 
+- run test code (Suggest run in Linux)
 
 | | |
 | :------------------------------------- | :----------------------------------------------- |
 |``make test[\#TestSpecificName]`` | run unit test |
-|``make test-sqlite[\#TestSpecificName]``| run [integration](integrations) test for SQLite | 
+|``make test-sqlite[\#TestSpecificName]``| run [integration](integrations) test for SQLite |
 |[More details about integrations](integrations/README.md) |
 
 ## Vendoring
@@ -127,14 +127,14 @@ the *[How to get faster PR reviews](https://github.com/kubernetes/community/blob
 it has lots of useful tips for any project you may want to contribute.
 Some of the key points:
 
-* Make small pull requests. The smaller, the faster to review and the
+- Make small pull requests. The smaller, the faster to review and the
  more likely it will be merged soon.
-* Don't make changes unrelated to your PR. Maybe there are typos on
+- Don't make changes unrelated to your PR. Maybe there are typos on
  some comments, maybe refactoring would be welcome on a function... but
  if that is not related to your PR, please make *another* PR for that.
-* Split big pull requests into multiple small ones. An incremental change
+- Split big pull requests into multiple small ones. An incremental change
  will be faster to review than a huge PR.
-* Use the first comment as a summary explainer of your PR and you should keep this up-to-date as the PR evolves.
+- Use the first comment as a summary explainer of your PR and you should keep this up-to-date as the PR evolves.
 
 If your PR could cause a breaking change you must add a BREAKING section to this comment e.g.:
 
@@ -146,7 +146,8 @@ To explain how this could affect users and how to mitigate these changes.
 
 ## Styleguide
 
-For imports you should use the following format (_without_ the comments)
+For imports you should use the following format (*without* the comments)
+
 ```go
 import (
  // stdlib
@@ -181,11 +182,15 @@ To maintain understandable code and avoid circular dependencies it is important
 ## API v1
 
 The API is documented by [swagger](http:https://try.gitea.io/api/swagger) and is based on [GitHub API v3](https://developer.github.com/v3/).
-Thus, Gitea´s API should use the same endpoints and fields as GitHub´s API as far as possible, unless there are good reasons to deviate. 
-If Gitea provides functionality that GitHub does not, a new endpoint can be created. 
+
+Thus, Gitea´s API should use the same endpoints and fields as GitHub´s API as far as possible, unless there are good reasons to deviate.
+
+If Gitea provides functionality that GitHub does not, a new endpoint can be created.
+
 If information is provided by Gitea that is not provided by the GitHub API, a new field can be used that doesn't collide with any GitHub fields.
 
 Updating an existing API should not remove existing fields unless there is a really good reason to do so.
+
 The same applies to status responses. If you notice a problem, feel free to leave a comment in the code for future refactoring to APIv2 (which is currently not planned).
 
 All expected results (errors, success, fail messages) should be documented
@@ -194,28 +199,33 @@ All expected results (errors, success, fail messages) should be documented
 All JSON input types must be defined as a struct in [modules/structs/](modules/structs/)
 ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/modules/structs/issue.go#L76-L91))
 and referenced in
-[routers/api/v1/swagger/options.go](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/options.go). 
+[routers/api/v1/swagger/options.go](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/options.go).
+
 They can then be used like the following:
 ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/repo/issue.go#L318)).
 
 All JSON responses must be defined as a struct in [modules/structs/](modules/structs/)
 ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/modules/structs/issue.go#L36-L68))
 and referenced in its category in [routers/api/v1/swagger/](routers/api/v1/swagger/)
-([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/issue.go#L11-L16)) 
+([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/swagger/issue.go#L11-L16))
+
 They can be used like the following:
 ([example](https://github.com/go-gitea/gitea/blob/c620eb5b2d0d874da68ebd734d3864c5224f71f7/routers/api/v1/repo/issue.go#L277-L279))
 
 In general, HTTP methods are chosen as follows:
- * **GET** endpoints return requested object and status **OK (200)**
- * **DELETE** endpoints return status **No Content (204)**
- * **POST** endpoints return status **Created (201)**, used to **create** new objects (e.g. a User)
- * **PUT** endpoints return status **No Content (204)**, used to **add/assign** existing Objects (e.g. User) to something (e.g. Org-Team)
- * **PATCH** endpoints return changed object and status **OK (200)**, used to **edit/change** an existing object
+
+- **GET** endpoints return requested object and status **OK (200)**
+- **DELETE** endpoints return status **No Content (204)**
+- **POST** endpoints return status **Created (201)**, used to **create** new objects (e.g. a User)
+- **PUT** endpoints return status **No Content (204)**, used to **add/assign** existing Objects (e.g. User) to something (e.g. Org-Team)
+- **PATCH** endpoints return changed object and status **OK (200)**, used to **edit/change** an existing object
 
 An endpoint which changes/edits an object expects all fields to be optional (except ones to identify the object, which are required).
+
 ### Endpoints returning lists should
- * support pagination (`page` & `limit` options in query)
- * set `X-Total-Count` header via **SetTotalCountHeader** ([example](https://github.com/go-gitea/gitea/blob/7aae98cc5d4113f1e9918b7ee7dd09f67c189e3e/routers/api/v1/repo/issue.go#L444))
+
+- support pagination (`page` & `limit` options in query)
+- set `X-Total-Count` header via **SetTotalCountHeader** ([example](https://github.com/go-gitea/gitea/blob/7aae98cc5d4113f1e9918b7ee7dd09f67c189e3e/routers/api/v1/repo/issue.go#L444))
 
 ## Large Character Comments
 
@@ -368,35 +378,35 @@ and lead the development of Gitea.
 To honor the past owners, here's the history of the owners and the time
 they served:
 
-* 2022-01-01 ~ 2022-12-31 - https://github.com/go-gitea/gitea/issues/17872
- * [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
- * [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
- * [Andrew Thornton](https://gitea.com/zeripath) <[email protected]>
+- 2022-01-01 ~ 2022-12-31 - https://github.com/go-gitea/gitea/issues/17872
+ - [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
+ - [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
+ - [Andrew Thornton](https://gitea.com/zeripath) <[email protected]>
 
-* 2021-01-01 ~ 2021-12-31 - https://github.com/go-gitea/gitea/issues/13801
- * [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
- * [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) <[email protected]>
- * [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
+- 2021-01-01 ~ 2021-12-31 - https://github.com/go-gitea/gitea/issues/13801
+ - [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
+ - [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) <[email protected]>
+ - [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
 
-* 2020-01-01 ~ 2020-12-31 - https://github.com/go-gitea/gitea/issues/9230
- * [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
- * [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) <[email protected]>
- * [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
+- 2020-01-01 ~ 2020-12-31 - https://github.com/go-gitea/gitea/issues/9230
+ - [Lunny Xiao](https://gitea.com/lunny) <[email protected]>
+ - [Lauris Bukšis-Haberkorns](https://gitea.com/lafriks) <[email protected]>
+ - [Matti Ranta](https://gitea.com/techknowlogick) <[email protected]>
 
-* 2019-01-01 ~ 2019-12-31 - https://github.com/go-gitea/gitea/issues/5572
- * [Lunny Xiao](https://github.com/lunny) <[email protected]>
- * [Lauris Bukšis-Haberkorns](https://github.com/lafriks) <[email protected]>
- * [Matti Ranta](https://github.com/techknowlogick) <[email protected]>
+- 2019-01-01 ~ 2019-12-31 - https://github.com/go-gitea/gitea/issues/5572
+ - [Lunny Xiao](https://github.com/lunny) <[email protected]>
+ - [Lauris Bukšis-Haberkorns](https://github.com/lafriks) <[email protected]>
+ - [Matti Ranta](https://github.com/techknowlogick) <[email protected]>
 
-* 2018-01-01 ~ 2018-12-31 - https://github.com/go-gitea/gitea/issues/3255
- * [Lunny Xiao](https://github.com/lunny) <[email protected]>
- * [Lauris Bukšis-Haberkorns](https://github.com/lafriks) <[email protected]>
- * [Kim Carlbäcker](https://github.com/bkcsoft) <[email protected]>
+- 2018-01-01 ~ 2018-12-31 - https://github.com/go-gitea/gitea/issues/3255
+ - [Lunny Xiao](https://github.com/lunny) <[email protected]>
+ - [Lauris Bukšis-Haberkorns](https://github.com/lafriks) <[email protected]>
+ - [Kim Carlbäcker](https://github.com/bkcsoft) <[email protected]>
 
-* 2016-11-04 ~ 2017-12-31
- * [Lunny Xiao](https://github.com/lunny) <[email protected]>
- * [Thomas Boerger](https://github.com/tboerger) <[email protected]>
- * [Kim Carlbäcker](https://github.com/bkcsoft) <[email protected]>
+- 2016-11-04 ~ 2017-12-31
+ - [Lunny Xiao](https://github.com/lunny) <[email protected]>
+ - [Thomas Boerger](https://github.com/tboerger) <[email protected]>
+ - [Kim Carlbäcker](https://github.com/bkcsoft) <[email protected]>
 
 ## Versions
 
@@ -413,20 +423,20 @@ be reviewed by two maintainers and must pass the automatic tests.
 
 ## Releasing Gitea
 
-* Let $vmaj, $vmin and $vpat be Major, Minor and Patch version numbers, $vpat should be rc1, rc2, 0, 1, ...... $vmaj.$vmin will be kept the same as milestones on github or gitea in future.
-* Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
-* If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
- * Create `-dev` tag as `git tag -s -F release.notes v$vmaj.$vmin.0-dev` and push the tag as `git push origin v$vmaj.$vmin.0-dev`.
- * When CI has finished building tag then you have to create a new branch named `release/v$vmaj.$vmin`
-* If it is bugfix version create PR for changelog on branch `release/v$vmaj.$vmin` and wait till it is reviewed and merged.
-* Add a tag as `git tag -s -F release.notes v$vmaj.$vmin.$`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
-* And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
-* If needed send a frontport PR for the changelog to branch `main` and update the version in `docs/config.yaml` to refer to the new version.
-* Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
-* Verify all release assets were correctly published through CI on dl.gitea.io and GitHub releases. Once ACKed:
- * bump the version of https://dl.gitea.io/gitea/version.json
- * merge the blog post PR
- * announce the release in discord `#announcements`
+- Let $vmaj, $vmin and $vpat be Major, Minor and Patch version numbers, $vpat should be rc1, rc2, 0, 1, ...... $vmaj.$vmin will be kept the same as milestones on github or gitea in future.
+- Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
+- If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
+ - Create `-dev` tag as `git tag -s -F release.notes v$vmaj.$vmin.0-dev` and push the tag as `git push origin v$vmaj.$vmin.0-dev`.
+ - When CI has finished building tag then you have to create a new branch named `release/v$vmaj.$vmin`
+- If it is bugfix version create PR for changelog on branch `release/v$vmaj.$vmin` and wait till it is reviewed and merged.
+- Add a tag as `git tag -s -F release.notes v$vmaj.$vmin.$`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
+- And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
+- If needed send a frontport PR for the changelog to branch `main` and update the version in `docs/config.yaml` to refer to the new version.
+- Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
+- Verify all release assets were correctly published through CI on dl.gitea.io and GitHub releases. Once ACKed:
+ - bump the version of https://dl.gitea.io/gitea/version.json
+ - merge the blog post PR
+ - announce the release in discord `#announcements`
 
 ## Copyright
 

Makefile

@@ -313,6 +313,7 @@ lint-frontend: node_modules
  npx eslint --color --max-warnings=0 --ext js,vue web_src/js build *.config.js docs/assets/js
  npx stylelint --color --max-warnings=0 web_src/less
  npx spectral lint -q -F hint $(SWAGGER_SPEC)
+ npx markdownlint docs *.md
 
 .PHONY: lint-backend
 lint-backend: golangci-lint vet editorconfig-checker

README.md

@@ -100,7 +100,7 @@ NOTES:
 
 ## Translating
 
-Translations are done through Crowdin. If you want to translate to a new language ask one of the managers in the Crowdin project to add a new language there. 
+Translations are done through Crowdin. If you want to translate to a new language ask one of the managers in the Crowdin project to add a new language there.
 
 You can also just create an issue for adding a language or ask on discord on the #translation channel. If you need context or find some translation issues, you can leave a comment on the string or ask on Discord. For general translation questions there is a section in the docs. Currently a bit empty but we hope to fill it as questions pop up.
 
@@ -113,15 +113,17 @@ https://docs.gitea.io/en-us/translation-guidelines/
 For more information and instructions about how to install Gitea, please look at our [documentation](https://docs.gitea.io/en-us/).
 If you have questions that are not covered by the documentation, you can get in contact with us on our [Discord server](https://discord.gg/Gitea) or create a post in the [discourse forum](https://discourse.gitea.io/).
 
-We maintain a list of Gitea-related projects at [gitea/awesome-gitea](https://gitea.com/gitea/awesome-gitea). 
-The Hugo-based documentation theme is hosted at [gitea/theme](https://gitea.com/gitea/theme). 
+We maintain a list of Gitea-related projects at [gitea/awesome-gitea](https://gitea.com/gitea/awesome-gitea).
+
+The Hugo-based documentation theme is hosted at [gitea/theme](https://gitea.com/gitea/theme).
+
 The official Gitea CLI is developed at [gitea/tea](https://gitea.com/gitea/tea).
 
 ## Authors
 
-* [Maintainers](https://github.com/orgs/go-gitea/people)
-* [Contributors](https://github.com/go-gitea/gitea/graphs/contributors)
-* [Translators](options/locale/TRANSLATORS)
+- [Maintainers](https://github.com/orgs/go-gitea/people)
+- [Contributors](https://github.com/go-gitea/gitea/graphs/contributors)
+- [Translators](options/locale/TRANSLATORS)
 
 ## Backers
 
@@ -161,6 +163,7 @@ See the [LICENSE](https://github.com/go-gitea/gitea/blob/main/LICENSE) file
 for the full license text.
 
 ## Screenshots
+
 Looking for an overview of the interface? Check it out!
 
 |![Dashboard](https://dl.gitea.io/screenshots/home_timeline.png)|![User Profile](https://dl.gitea.io/screenshots/user_profile.png)|![Global Issues](https://dl.gitea.io/screenshots/global_issues.png)|

SECURITY.md

@@ -1,6 +1,7 @@
 # Reporting security issues
 
-The Gitea maintainers take security seriously. 
+The Gitea maintainers take security seriously.
+
 If you discover a security issue, please bring it to their attention right away!
 
 ## Reporting a Vulnerability
@@ -11,12 +12,16 @@ Please **DO NOT** file a public issue, instead send your report privately to `se
 
 Due to the sensitive nature of security information, you can use below GPG public key encrypt your mail body.
 
-The PGP key is valid until June 24, 2024. 
-Key ID: 6FCD2D5B 
-Key Type: RSA 
-Expires: 6/24/2024 
-Key Size: 4096/4096 
-Fingerprint: 3DE0 3D1E 144A 7F06 9359 99DC AAFD 2381 6FCD 2D5B 
+The PGP key is valid until June 24, 2024.
+
+```
+Key ID: 6FCD2D5B
+Key Type: RSA
+Expires: 6/24/2024
+Key Size: 4096/4096
+Fingerprint: 3DE0 3D1E 144A 7F06 9359 99DC AAFD 2381 6FCD 2D5B
+```
+
 UserID: Gitea Security <[email protected]>
 
 ```

docs/content/doc/advanced/clone-filter.en-us.md

@@ -30,7 +30,6 @@ see Git version of the server.
 By default, clone filters are enabled, unless `DISABLE_PARTIAL_CLONE` under
 `[git]` is set to `true`.
 
-
 See [GitHub blog post: Get up to speed with partial clone](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/)
 for common use cases of clone filters (blobless and treeless clones), and
 [GitLab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html)