Although it would be possible to modify these files, it would create
conflicts when rebasing. Instead, this commit removes them entirely
and another commit can start from scratch, borrowing content from the
original files.
The drawback of this approach is that some content updates from Gitea
that also need updating in Forgejo will have to be copy/pasted
instead of being merged.
(cherry picked from commit eb85782115)
(cherry picked from commit 34401f2004)
(cherry picked from commit ef43b1c691)
(cherry picked from commit d17fe25e2f)
(cherry picked from commit 3f65dea3e7)
(cherry picked from commit 3cacb64a1b)
(cherry picked from commit b531b014b7)
(cherry picked from commit adf6e7a840)
(cherry picked from commit 68c19d977d)
(cherry picked from commit 31aa8647ec)
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.
