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>
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>
basically redoing #3559 as it got impossible to merge with the many
changes since it was open (which is totally my fault for not merging it
earlier).
Anyhow, still a WIP, going also doing some other related improvements in
the way.
cc/ @graytonio
closes#3559closes#3525
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Co-authored-by: Grayton Ward <graytonio.ward@gmail.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>
alternative to #3806
the idea is that both `context.New` and `context.Context{}` are never
used in tests.
not sure yet how much I like it, so far code does look a bit more
readable though.
---------
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
Hi, I found a bug in the GitLab client that leads to not correctly
prepend/append/keep releases notes.
This will use the original `Description` instead of the pre-rendered
`DescriptionHTML`. Furthermore, as `include_html_description` is not
enabled, the `DescriptionHTML` field is always empty.
[GitLab
documentation](https://docs.gitlab.com/ee/api/releases/index.html#get-a-release-by-a-tag-name)
# 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>
closes#3508
- adds template support for krew and scoop repo refs
- template branch on reporef on brew as well
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
If applied, this commit will allow for new GitLab clients to use both ci
job tokens and plain tokens (for things like brew publishing where the
CI_JOB_TOKEN isn't applicable)
This provides a fix for #3399
---
closes#3399
Co-authored-by: Carlos Alexandro 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: replacing logs
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: tests et al
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* feat: update termenv/lipgloss
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* wip: output
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: pin dep
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: update
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: tests
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: tests
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: deps
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
* fix: dep
Signed-off-by: Carlos A Becker <caarlos0@users.noreply.github.com>
