this is different from the default signs, in the sense that this will
sign the binaries even if archive mode is not set to binary.
refs https://github.com/orgs/goreleaser/discussions/4989
---------
Signed-off-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>
v1.24 announcement, release planned for tomorrow.
This also includes the updated docs generated from goreleaser pro source
code.
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
the sidebar is kinda out of control... too many items... tried to
organize it a bit better...
let me know what you think :D
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
this will add support to winget into goreleaser.
Basically, the plan is:
- we generate the 3 needed yaml files
- we commit them to a repo
and that's it.
Initially, will probably have limited options support, and will only
have the default locale.
###### TODO
- [x] docs
- [x] review by someone who knows how this works?
- [x] test install somewhere
- [x] more tests maybe?
- [x] PR templates via API?
https://github.com/goreleaser/goreleaser/pull/4105
- [x] real project test
- [x] setup goreleaser to pr to winget as well
- [x] document sync fork stuff
https://github.com/goreleaser/goreleaser/pull/4106
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
I was really tired of copying and pasting that over and over again and
keeping it all in sync...
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
very, very, very WIP implementation of nixpkgs for GoReleaser.
**Decisions made for this first version:**
- only linux and darwin, arm64, 386 and amd64
- only support pkgs from goreleaser-generated archives
- no support to push into default nixpkgs repository
- no support to automatically add the _maybe_ new pkg to the root
`default.nix`
- the generated nixpkg will be rather verbose, which shouldn't be too
much of an issue as it is autogenerated anyway
**TODOs**:
- [x] macos universal binary support
- [x] custom pkg path (e.g. pkgs/misc/foo/bar/default.nix)
- [x] handle archives with a folder in them
- [x] add more options: postInstall, ??
**Will be handled in future versions**:
- [ ] archives.format=binary support
- [ ] compile from source
- [ ] PR-ing into nixpkgs
- [ ] armv6l-linux & armv7l-linux support
closes#3537
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
this adds a new root-level `upx` config, so users can pack their
binaries with upx :)
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
This adds a log with the size of the generated binaries/packages/etc in
the end of the build process, and also adds it to the artifacts.json
closes#3949
TODO:
- [x] tests
- [x] docs
- [ ] ??
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
This option was still being supported, even though undocumented, for
many years now.
I think it's finally time to sunset it for good, in 6 months :)
---------
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
continuing the PR by @developer-guy
- [x] should be a publisher, as it does publish the images it builds
every time
- [x] `Default` method does not work
- [x] the `fromConfig` thing should probably be on the defaults, too
- [x] wire `--skip-ko`
- [x] documentation
- [x] more tests
- [x] use same registry as docker tests does
- [ ] see if we can make the log output match goreleaser's
- [ ] ??
closes#2556closes#3490
Signed-off-by: Batuhan Apaydın <batuhan.apaydin@trendyol.com>
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
Co-authored-by: actions-user <actions@github.com>
Co-authored-by: Jason Hall <jason@chainguard.dev>
Co-authored-by: Batuhan Apaydın <batuhan.apaydin@trendyol.com>
This PR adds support for generating the structure used to pack and push
Chocolatey Packages. And will solve the #3154
Is not ready for merge yet, but has the main structure, and ready for
comments.
Accordingly to Chocolatey, in order to build a package, it's necessary a
`.nuspec` and `chocolateyinstall.ps1` files at least, having these ones,
we could pack and distribute without adding the binary inside the final
package and that was implemented here.
To complete, will be necessary to define the package build and
distribute, however will be required to have Chocolatey installed
(Windows Only). One of alternatives that I thought was, publish the
files like Scoop and Brew in a separate repository, and there we could
use `chocolatey` through
[crazy-max/ghaction-chocolatey](https://github.com/crazy-max/ghaction-chocolatey).
Chocolatey has a lot of good examples of repositories:
https://github.com/chocolatey-community/chocolatey-packages/tree/master/automatic/curl
A final compilation of the missing parts:
- [x] How to pack and push (chocolatey)
- [x] Documentation
Sorry for the long description😄
All feedback very welcome!
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
