Previously end-users would see missing artifacts if trying to use latest
version while artifacts are being uploaded.
This currently applies only to GitHub releases. GitLab does not support
drafts, and I don't dare to make the change for Gitea since I don't use
it (and can't test easily).
---------
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... -->
...
<!-- Why is this change being made? -->
...
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
...
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
github api is eventually consistent... so, we might ask for the branch,
it might say it does't exist, and when we try and create it, it might
error because it already exists.
this should avoid breaking it
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
if the base branch is empty, it'll try to fetch the default branch,
which would fail if base repo name/owner are also empty.
the default behavior when base owner/name are missing is to using
head's, so I changed it do that before trying to get the default branch,
which should fix the issue.
<!--
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? -->
...
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
...
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
This commit adds a `make_latest` boolean to the release configuration,
to allow signaling to GitHub if the release should be marked as latest.
Albeit being a boolean, the internal Go type is a string to allow
to distinguish an empty string (default behavior: `true`) from an
explicit `false`.
For more information around the GitHub API field, see
https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release
I did not include the `legacy` option, to not adopt something which
appears to be scheduled for removal in the future.
In addition, I opted for `make_latest` over `latest` because the
option is only available for GitHub. Which keeps the latter key
reserved for e.g. future use of a config option which is used across
Git providers.
Fixes#4159
Signed-off-by: Hidde Beydals <hidde@hhh.computer>
check if there is a `.github/PULL_REQUEST_TEMPLATE.md` file, and use it
as body of the pull request if there is.
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
This allows to open pull requests across repositories on nix, brew, krew
and scoop.
closes#4048
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
- log keys will be ordered as intended instead of sorted
- paths always relative to cwd
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
closes#3485
also fixed a bug in file creation for github: it was always searching
for the file in the default branch
also, we don't need to create the file first, update does both create
and update.
TODO: implement the for krew, scoop, etc...
---------
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
# If applied, this commit will
Linked issues will be resolved.
# Why is this change being made?
Because the program will no longer have to refer to nil.
# Provide links to any relevant tickets, URLs or other resources
- https://github.com/goreleaser/goreleaser/issues/3669
this should help when reporting issues to github, especially the magical
"failed successfully" error
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
It makes no sense, but I saw it happens some times... the release will
be created as a draft, even though there's nothing telling it to do so.
Editing the release later might do the trick, hopefully.
closes#3541
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
this allows the user to specify the abbrev lenght to use, and will also add the option to omit the commit hash altogether by setting it to -1.
default is doing nothing
closes#3348
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
We should not imply the target_commitish, as some users might want to
have the code in one repo and the releases in another (e.g. private
code, public releases), so the commit might not be there.
We should instead allow the user to set the `target_commitish` (or not),
and pass it down to the github api.
refs 95bba02211
refs #3044
refs #3330
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
closes#3044
What happens is that, if the tag is created only locally, it'll create the tag in the remote upon creating the release. The tag still needs to be created locally though!
@bep let me know if that works for you.
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* feat: allow to customize release notes update behavior
closes#1384
Signed-off-by: Carlos A Becker <caarlos0@gmail.com>
* fix: make it a bit better
Signed-off-by: Carlos A Becker <caarlos0@gmail.com>
* fix: jsonschema
Signed-off-by: Carlos A Becker <caarlos0@gmail.com>
