mirrors/gotosocial
1
0
Fork 0
mirror of https://github.com/superseriousbusiness/gotosocial.git synced 2025-11-26 03:13:35 -06:00
Code Issues Projects Releases Packages Wiki Activity Actions

[chore]: Bump github.com/microcosm-cc/bluemonday from 1.0.26 to 1.0.27 (#3081)

Browse source
This commit is contained in:
dependabot[bot] 2024-07-08 07:34:39 +00:00 • committed by GitHub
commit 5769722c58
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
19 changed files with 57 additions and 204 deletions
Download patch file Download diff file Expand all files Collapse all files

9
vendor/github.com/microcosm-cc/bluemonday/CONTRIBUTING.md generated vendored
View file

@ -8,7 +8,7 @@ Third-party patches are essential for keeping bluemonday secure and offering the
## Guidelines
1. Do not vendor dependencies. As a security package, were we to vendor dependencies the projects that then vendor bluemonday may not receive the latest security updates to the dependencies. By not vendoring dependencies the project that implements bluemonday will vendor the latest version of any dependent packages. Vendoring is a project problem, not a package problem. bluemonday will be tested against the latest version of dependencies periodically and during any PR/merge.
1. Do not vendor dependencies. Vendoring is a project problem, not a package problem.
2. I do not care about spelling mistakes or whitespace and I do not believe that you should either. PRs therefore must be functional in their nature or be substantial and impactful if documentation or examples.
3. This module does not participate in hacktober, please make your contributions meaningful.
@ -31,10 +31,9 @@ If you are reporting a security flaw, you may expect that we will provide the co
1. Include tests for your patch, 1 test should encapsulate the entire patch and should refer to the Github issue
1. If you have added new exposed/public functionality, you should ensure it is documented appropriately
1. If you have added new exposed/public functionality, you should consider demonstrating how to use it within one of the helpers or shipped policies if appropriate or within a test if modifying a helper or policy is not appropriate
1. Run all of the tests `go test -v ./...` or `make test` and ensure all tests pass
1. Run gofmt `gofmt -w ./$*` or `make fmt`
1. Run vet `go tool vet *.go` or `make vet` and resolve any issues
1. Install golint using `go get -u github.com/golang/lint/golint` and run vet `golint *.go` or `make lint` and resolve every warning
1. Run all of the tests `go test -v ./...` and ensure all tests pass
1. Run gofmt `go fmt ./...`
1. Run vet `go vet ./...` and resolve any issues
* When submitting the pull request you should
1. Note the issue(s) it resolves, i.e. `Closes #6` in the pull request comment to close issue #6 when the pull request is accepted