- Merge the file filters into `files-changed.yml`
- Remove unused yaml anchors like `&backend`
- Merge the `compliance-docs` workflow into `compliance`
- Add actions linting
- Misc cleanups for whitespace and step names

Fix documentation ref

Inspired by
https://github.com/go-gitea/gitea/pull/24530#issuecomment-1558815301

This PR use a file filter action to do different CI jobs according
changed files types. All types are defined in
`.github/file-filters.yml`. Now there are 4 types, `docs`, `backend`,
`frontend` and `build`. Then if a PR only changed docs files, those CI
jobs which passed the conditions will run, and other types are also like
this.

---------

Co-authored-by: silverwind <me@silverwind.io>

Now that the redirect to docs.gitea.com is in place this is no longer
needed.

Fix https://github.com/go-gitea/gitea/pull/24530#issuecomment-1550227919

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

Fix cron translations push failure

minio storage iterator shows different behavior with local fs iterator.

in local fs storage:

``` go
s.IterateObjects("prefix", func(path,obj)
     println(path) // show "prefix/xxx.file"
})
```

in minio storage:

```go
s.IterateObjects("prefix", func(path,obj)
     println(path) // show "xxx.file"
})
```

I think local fs is correct, minio use wrong `basePath` to trim storage
path prefix.

---------

Co-authored-by: Giteabot <teabot@gitea.io>

- Remove actions name where command is descriptive enough
- Use kebab-case instead of snake-case for step names
- Use shorter job names because to make PR checks more readable
- Remove duplicate `checks-backend`

---------

Co-authored-by: Yarden Shoham <git@yardenshoham.com>

Replaces #24641

Currently, unit tests fail when run locally (unless users have minio
instance running). This PR only requires redis unit tests if in CI.

- Only run redis unit tests when `CI` env variable is set
- Add minio as a service in unit tests actions

With comments happening on closed issues/prs this locks issues that have
been closed for >45days. This allows for comments on recently closed
issues/prs to still happen.

---------

Co-authored-by: silverwind <me@silverwind.io>

- Upgrade node, the
[snap](7abe958f5b/snap/snapcraft.yaml (L47))
is excluded from this because [there is no Node 20 snap
yet](https://snapcraft.io/node).
- Add actions build cancellation based on
[this](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-using-a-fallback-value).

---------

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

following https://github.com/go-gitea/gitea/pull/24314 and
https://github.com/go-gitea/gitea/pull/24434, this PR moves drone cron
pipelines to (GitHub) Actions. As these are mostly compatible with Gitea
Actions, when we start to dogfood, these will already be migrated.

---------

Co-authored-by: silverwind <me@silverwind.io>

As before with past PRs to switch Drone pipelines to use (GitHub)
Actions.

---------

Co-authored-by: silverwind <me@silverwind.io>

similar to #24314, this moves drone cron pipelines to (GitHub) Actions.
As these are mostly compatible with Gitea Actions, when we start to
dogfood, these will already be migrated.

I also removed the discord notify pipeline, as it hasn't been working
for several months.

Move drone cron pipelines to (GitHub) Actions. As these are mostly
compatible with Gitea Actions, when we start to dogfood, these will
already be migrated.

Update `pull_request_template.md` because:

- It's a kind idea to hide the tips. However, it's easier to include
them in the commit message by mistake when you cannot see them. Check
`git log | grep 'Please check the following:'`. So don't hide it, expose
it and help fix it.
- "for backports" is much clearer than "for bug fixes". I saw someone
post a PR to a release branch because they believed it was the right way
for a bugfix.
- "Allow edits by maintainers", or we have to ask the contributor to
update the branch and they could be confused.
- Remind the contributor that the words could be included in the commit
message, to avoid some words like "Hello", "Sorry". If they really need
them, they can separate them with a line, like:

```markdown
Close #xxxx
Because ... Then ... Finally ...
---
Hello, this is my first time opening a pull request. Sorry for any mistakes.
```
And the merger should be careful, check and delete the extra content
before merging.

---------

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

* Reorder bug-report.yaml

* Add bug label on bug-report.yaml

* Add feature label on feature-request.yaml

* Reorder ui.bug-report.yaml

* Apply suggestions

Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: zeripath <art27@cantab.net>

It is ridiculous how few of our bug reporter are giving us DEBUG level logs.
This has to change and I think the proforma is not making it clear enough that
they have to give us these logs.

This PR changes the issue proformas to tell people to give us these logs.

Signed-off-by: Andrew Thornton <art27@cantab.net>

* `git` -> `Git`
* `Github` and `github` -> `GitHub`
* `crowdin` -> `Crowdin`
* `git-lfs` -> `Git LFS`
* `githooks`, `git hooks`, `git-hooks` -> `Git Hooks`
* `discord` -> `Discord`
* `2fa` -> `2FA`
* `gitlab` and `Gitlab` -> `GitLab`
* `web hook` -> `webhook`
* `linux` -> `Linux`
* `sqlite` -> `SQLite`
* `MYSQL` and `mysql` -> `MySQL`
* rename refs to `master` branch -> `main`
* Fix English grammar

Co-authored-by: John Olheiser <john.olheiser@gmail.com>

There was a typo `systemm` here. I opted to just remove the superfluos word altogether.

* Create issue template using new format

This issue template has been based off of the current issue creation workflow defined in the ISSUE_TEMPLATE.md file
This commit allows for that issue template (which is a legacy method of creating an issue) to be deleted

* Delete old issue template file

This commit deletes the old issue template file, as it is both legacy and replaced by ISSUE_TEMPLATE/issue.yaml

* Adjust file upload and remove code of conduct checkbox

* Block blank issue creation

* Update feedback

Removed most requirements
Updated prompt to include instruction to state whether using try.gitea.io
Added default value to Gitea version

* Create Feature Request issue form

* Update and rename issue.yaml to bug-report.yaml

* Enable blank issue creation

Co-authored-by: a101211279 <1012112796@qq.com>

* Update config.yaml

* Remove default & placeholder from Gitea version

* Create issue template in .gitea directory

* Add relevant bug report message to feature request

* Adjust name to remove banner

There is a banner that tells you to create a config.yml when you already have a config.yaml
Renaming the file stops this from occurring.

* Add UI bug report form

* Remove unnecessary question

Co-authored-by: a101211279 <1012112796@qq.com>
Co-authored-by: techknowlogick <techknowlogick@gitea.io>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lauris BH <lauris@nix.lv>

Branch name
- master -> main

* chore: are you using Gitea behind CloudFlare

since more often than not CF appears to serve stale cache and cause
troubles, I'd argue it might be helpful to ask about it in this here
issue template

* implement suggestion: change question to comment

* as per @techknowlogick's suggestion

* chore: edit comment

* implement @mrsdizzie's suggestion
* as the comment grows, rather span multiple lines
* Gitea --> gitea to match case used in the rest of the template

Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>

* Add bountysource to Sponsors link

* Add badge to readme

* config lock bot

* Update .github/lock.yml

Signed-off-by: Andrew Thornton <art27@cantab.net>

Co-authored-by: techknowlogick <techknowlogick@gitea.io>

Almost every use of "Not relevant" I see is the opposite -- it is relevant to have an example on try.gitea.io and often we can't do anything until the user provides one. Remove the not-relevant option so people have to decide yes/no if they are going to attempt to reproduce it which will hopefully encourage them to do so in simple cases. 

For actual not-relevant issues No should be a fine answer as well as it would be clear to us when you can't reproduce an example there.

Hopefully this will encourage more examples when people file issues which would lead to quicker fixes.

* Improve stale nessage

* Update .github/stale.yml

Co-authored-by: guillep2k <18600385+guillep2k@users.noreply.github.com>

This need an option to be enabled on repo : https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository

Like the comment that is posted.

Ex: https://github.com/go-gitea/gitea/pull/4749 is closed after 2 weeks and not 2 months

For `UI`-bugs we usually require a Screenshot to debug it :wink: