Tried to do a release a few days ago (after go1.24.5 became available in Github Actions) and found that our release process was breaking on the s3 provider with the following error:

blobs: failed to publish artifacts: failed to write to bucket: blob (key "my-build-key") (code=Unknown): could not apply before write
Error: The process '/opt/hostedtoolcache/goreleaser-action/2.11.0/x64/goreleaser' failed with exit code 1

I verified that nothing in the repository secrets and/or build process had changed since our last release a few months ago. I looked at the logs from the last successful release and the only difference was the version of goreleaser that was used (v2.9.0). I retried my new release and pinned to v2.9.0 in the goreleaser action parameters and the release completed successfully.

Next, I tested again with v2.11.0 and confirmed that the workflow broke again with the same error. Finally, I tested with v2.10.2 to see if I could narrow down the version of goreleaser with which the failure was associated. Using v2.10.2, the release again completes without issue. This is leading me to believe that something changed with the s3 provider between these two releases (v2.10.2 - v2.11.0).

I've looked through the deprecation notices for s3 in the goreleaser docs and don't see anything relevant to the latest release. I did notice the following (in the s3 provider section): "ACLs should be set on the bucket, the acl option does not exist anymore." We have been using the ACL attribute as follows: https://github.com/smallstep/cli/blob/master/.goreleaser.yml#L277. The deprecation warning was added 6 years ago, and yet we have not had any issues using the ACL attribute (in the s3 provider blob). On a whim, I tried removing the ACL attribute and found that now the release succeeds with goreleaser v2.11.0. However, as expected, the ACLs on the newly uploaded artifacts are not appropriately set.

Some questions:

• Is this the new expected behavior for the s3 provider moving forwards (complete removal of ACL support)?
  • If so, I would recommend failing with a clearer error message. I'm not very clever and it took me a long while to figure out what might be happening under the hood. E.g., fail early if the attribute is defined.
• Since this was seemingly working fine up through the previous minor version, why the change in support?