So I found this [linter](https://github.com/Riverside-Healthcare/djlint)
which features a mode for go templates, so I gave it a try and it did
find a number of valid issue, like unbalanced tags etc. It also has a
number of bugs, I had to disable/workaround many issues.
Given that this linter is written in python, this does add a dependency
on `python` >= 3.8 and `poetry` to the development environment to be
able to run this linter locally.
- `e.g.` prefixes on placeholders are removed because the linter had a
false-positive on `placeholder="e.g. cn=Search"` for the `attr=value`
syntax and it's not ideal anyways to write `e.g.` into a placeholder
because a placeholder is meant to hold a sample value.
- In `templates/repo/settings/options.tmpl` I simplified the logic to
not conditionally create opening tags without closing tags because this
stuff confuses the linter (and possibly the reader as well).
The `setup-go` actions did not all have `check-latest` which means they
use some cached version of go that currently still resolves to go1.20.4,
as seen in a number of recent runs that currently fail at govulncheck
because of it:
````
Run actions/setup-go@v4
Setup go version spec >=1.20
Attempting to resolve the latest version from the manifest...
matching >=1.20...
Resolved as '1.20.4'
````
Add the
[check-latest](https://github.com/actions/setup-go#check-latest-version)
option which should guarantee that this cache is skipped.
- 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
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>
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>
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>
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>
* 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: a1012112796 <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: a1012112796 <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>
* 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>
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.
I've noticed that a lot of issues cannot be reproduced on http://try.gogs.io,
which either hints about specific database type problems or
hints about bugs which are already solved in the newer version
(as http://try.gogs.io is usually a newer build).
This patch adds the suggestion to test the issue at http://try.gogs.io in
the Github "issue template". The user can answer: "Yes", "No", "Not relevant".
"Not relevant" is an option where testing on http://try.gogs.io makes no sense as
the bug is unrelated to the Web UI or is very specific in nature.
