For pull request templates, Forgejo currently does not look in the `docs` directory, but [GitHub does](https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository#adding-a-pull-request-template). By making Forgejo also look there, it becomes possible to have the same repository work on both sites, without the need for vendor-specific paths.
There was duplication in the list of accepted file paths. On the one hand it’s nice for greppability that they are all spelled out, but it does mean adding 6 variants, I thought it would be more maintainable to deduplicate the Cartesian product. I added one fully spelled out path in the comment to still maintain some greppability.
Resolvesforgejo/forgejo#8284
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8863
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Ruud van Asseldonk <dev@veniogames.com>
Co-committed-by: Ruud van Asseldonk <dev@veniogames.com>
- gopkg.in/yaml.v3 is archived and unmaintained
- go.yaml.in/yaml/v3 is a compatible fork under the umbrella
of https://yaml.org/
### Tests
There is no need for more tests than already provided: it is like an upgrade to a minor version, only from a fork. I browsed the changes and there are some bug fixes. They all seem reasonably minimal. It is not one of those forks that went crazy with breaking changes 😁 And there is a non zero chance that [a bug that matters to Forgejo Actions](https://github.com/yaml/go-yaml/issues/76) is fixed there. It is rare and can wait but it did happen on Codeberg.
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8956
Reviewed-by: oliverpool <oliverpool@noreply.codeberg.org>
Co-authored-by: Earl Warren <contact@earl-warren.org>
Co-committed-by: Earl Warren <contact@earl-warren.org>
(cherry picked from commit f4d3aaeeb9e1b11c5495e4608a3f52f316c35758)
Conflicts:
- modules/charset/charset_test.go
Resolved by manually changing a `=` to `:=`, as per the
original patch. Conflict was due to `require.NoError`.
Blank Issues should be enabled if they are not explicit disabled through
the `blank_issues_enabled` field of the Issue Config. The Implementation
has currently a Bug: If you create a Issue Config file with only
`contact_links` and without a `blank_issues_enabled` field,
`blank_issues_enabled` is set to false by default.
The fix is only one line, but I decided to also improve the tests to
make sure there are no other problems with the Implementation.
This is a bugfix, so it should be backported to 1.20.
1. Remove unused fields/methods in web context.
2. Make callers call target function directly instead of the light
wrapper like "IsUserRepoReaderSpecific"
3. The "issue template" code shouldn't be put in the "modules/context"
package, so move them to the service package.
---------
Co-authored-by: Giteabot <teabot@gitea.io>
