The PR enables
[`nolintlint`](https://golangci-lint.run/usage/linters/#nolintlint)
linter and fixes up appeared issues.
Changes:
- Enable `nolintlint` in `.golangci.yml` config.
- Remove unused `//nolint:` comments.
- Fix `nolint` comment format by removing spaces (`// nolint: dupl` ->
`//nolint:dupl`)
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
The PR cleans up unnecessary loop variable copying and enables the
[`copyloopvar`](https://golangci-lint.run/usage/linters/#copyloopvar)
linter for detecting this redundant variable copying.
#### Additional notes
After the project upgraded to Go version 1.22 in #4779, copying
variables inside a `for` loop became unnecessary. See this [blog
post](https://go.dev/blog/loopvar-preview) for a detailed explanation.
The `copyloopvar` linter is only available from `golangci-lint` v1.57
onwards, so we also need to update this tool.
This change would allow users to disable the `Content-Disposition`
header that is set for blob storage operations. The application will
continue to set a default value for `Content-Disposition` of
`attachment; filename={{.Filename}}` if no value was provided by the
user. However, with this change, users can now specifically disable this
header by setting the value to "-" in the configuration.
We feel this would be a nice solution for this issue:
https://github.com/Homebrew/brew/issues/15604
<!--
Hi, thanks for contributing!
Please make sure you read our CONTRIBUTING guide.
Also, add tests and the respective documentation changes as well.
-->
<!-- If applied, this commit will... -->
...
<!-- Why is this change being made? -->
Brew linter says that old constructions can't be used in case of
submitting to brew-core
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
...
This allows to use templates for commit messages in the changelog when
using `github`, `gitea`, or `gitlab` as the changelog implementation.
closes#4800
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
**Depends on #4792**
This adds support for opening pull requests on brew, krew, nix, scoop
and winget changes with Gitlab.
---------
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Creating files on a new branch is only possible with the API if
`start_branch`
is given otherwise the API returns:
> You can only create or edit files when you are on a branch
Fixes https://github.com/goreleaser/goreleaser/issues/4543
---------
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
- Add `strings` package import to `gitea.go`
- Implement `Changelog` function in `gitea.go`
- Update `useGitea` constant in `changelog.go`
- Add test for `useGitea` in `changelog_test.go`
- Update `changelog.md` with information about `gitea` customization
ref:
* Server API: https://github.com/go-gitea/gitea/pull/30349
* SDK: https://gitea.com/gitea/go-sdk/pulls/659
---------
Signed-off-by: appleboy <appleboy.tw@gmail.com>
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
<!--
Hi, thanks for contributing!
Please make sure you read our CONTRIBUTING guide.
Also, add tests and the respective documentation changes as well.
-->
<!-- If applied, this commit will... -->
If applied, this commit will allow users to create BlueSky posts
(skeets) about their Goreleaser-built projects
<!-- Why is this change being made? -->
Because I wanted to post to BlueSky when projects I work on relating to
BlueSky are built!
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
Example post made during unit testing (requires an account to see):
https://bsky.app/profile/jaygles.bsky.social/post/3kpv573c2pc2k
---------
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
this includes anchore/quill as a pipe to sign and notarize macos
binaries
TODO:
- [x] find a way to test this
- [x] docs
- [x] maybe get someone from anchore to take a look?
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
if the output is not empty, log it with info.
this prevents potentially hiding warnings et al.
on successful builds usually the output is empty anyway.
closes#4782
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
- add the file type in the end of the sbom generated file
- fix wrong value attribution in the doc example
---------
Signed-off-by: cpanato <ctadeu@gmail.com>
