Closes#4421
I chose to keep `getProfileID` as `getProfileIDLegacy` and use it as a
fallback if `getProfileSub` fails because of permission scope.
In this way, it's not a breaking change because one that has only a
deprecated permissions such as `r_liteprofile` will still be able to hit
`v2/me`
this logic is encapsulated in the new function `getProfileURN`, that
resolves the user identifier and returns it formatted as a URN
---------
Co-authored-by: Gabriel F Cipriano <gabriel.cipriano@farme.com.br>
the release's defaults run before the project's does, so, usually the
github/gitlab/gitea names are set.
however, in some cases, the release's defaults might be skipped, in
which case they'll be empty.
this breaks things like `goreleaser changelog`, especially on non-go
repositories.
this pr tries to extract the project name from the git remote url in the
project's defaulter.
it might be possible now to move it to run before the release defaulter,
even.
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
also regex is not possible there currenctly, didnt realized it at the
time
refs #4255
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
the paths of the artifacts always use forward slashes, and the logic to
handle the relative path stuff inside the sbom pipe did not account for
that.
running the paths through `filepath.Clean` beforehand fixes it.
also improved yamlschema a little bit :)
closes#4289
Laying the ground work to allow skipping more pipes without adding new
flags et al.
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
tested this on a fake repo, and it seems to fix the problem...
seems like choco does not like when the path has `/` in it, so passing
it through `filepath.Clean` fixes it.
also improved tests a bit, and made a small docs fix.
closes https://github.com/goreleaser/goreleaser/issues/4292
<!--
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... -->
The gomod pipe will skip if the Go version does not support modules.
<!-- Why is this change being made? -->
I tried to use goreleaser to build a project with Go v1.8.7 and it
failed on `loading go mod information` step. The Go version used doesn't
support `go list -m`.
The build failed with the following error:
```
• loading go mod information
⨯ release failed after 0s error=failed to get module path: exit status 2: flag provided but not defined: -m
usage: list [-e] [-f format] [-json] [build flags] [packages]
List lists the packages named by the import paths, one per line.
...
```
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
...
the publish pipe, which runs all publishers, already skips all
publishers if skip publish is set, so this check is not needed here.
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
the publish pipe, which runs all publishers, already skips all
publishers if skip publish is set, so this check is not needed here.
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
the publish pipe, which runs all publishers, already skips all
publishers if skip publish is set, so this check is not needed here.
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Currently, GoReleaser will assume you're running against github, gitea
or gitlab.
You could set `release.disable: true`, but it would still set and try to
use some defaults that could break things up.
Now, if you disable the release, goreleaser will not set these defaults.
It'll also hard error in some cases in which it would happily produce
invalid resources before, namely, if `release.disable` is set, and, for
example, `brews.url_template` is empty (in which case it would try to
use the one from the release, usually github).
closes#4208
