The presence of an artifact field in the `signature` or `certificate`
template field caused a silent failure in the template when re-applied
after the external signing process was called.
This was due to the artifact being presence in the template context
before the signing process, but not after. An error here was also
ignored.
The fix supplies the artifact to the template context, and also allows a
template failure to
fail the overall process.
As far as I can tell, this change aligns behaviour to match existing
documentation.
Fixes#5147
This commit fixes the automatic extension when building the wasip1_wasm
target.
Additionally, in future Go versions, support will be added for
generating c-shared WASM binaries.
https://github.com/golang/go/issues/65199
Therefore, this PR corrects the extension in the build process and
removes the .h file from the release when c-shared is enabled and the
target is WASM.
this makes ko run on snapshot builds, too.
the image will be `goreleaser.ko.local:[your tags]`, not sure if we can
change this, seems like we can't.
also fixed a small doc error around it, as well as added a new test to
cover this.
closes#4683
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
make them more precise, as its currently only taking GOOS/GOARCH into
account, and we can do more.
closes#5112
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
When trying to release an artifact to github and it fails, I observed
the following stacktrace:
```
• publishing
• scm releases
• releasing tag=v1.11.0 repo=my-github-repo
• could not check rate limits, hoping for the best...
• could not check rate limits, hoping for the best...
• took: 1m40s
• took: 1m40s
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xe28b72]
goroutine 55 [running]:
github.com/goreleaser/goreleaser/v2/internal/client.(*githubClient).createOrUpdateRelease(0xc0001b24c8, 0xc0002c5108, 0xc000b478, {0xc00039ed00, 0x80e})
github.com/goreleaser/goreleaser/v2@v2.2.0/internal/client/github.go:454 +0x3b2
github.com/goreleaser/goreleaser/v2/internal/client.(*githubClient).CreateRelease(0xc0001b24c8, 0xc0002c5108, {0xc00039ed00, 0x80e})
github.com/goreleaser/goreleaser/v2@v2.2.0/internal/client/github.go:402 +0x339
github.com/goreleaser/goreleaser/v2/internal/pipe/release.doPublish(0xc0002c5108, {0x2ce2d40, 0xc0001b24c8})
...
```
I believe this happens because if the
[CreateRelease](c96ef954c3/github/repos_releases.go (L221))
fails, resp might be empty and the resp.Header does not exist, which
causes a segfault.
```
WithField("request-id", resp.Header.Get("X-GitHub-Request-Id")).
```
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
Ignore empty flags after templating is applied for final Go build line.
This caused us some problems since we had an `if` without `else`,
resulting in an empty flag, causing the whole build to fail with a
misleading error message like:
```
malformed import path "-myflag": leading dash
```
forcing `awssdk=v1` for now.
will probably need to remove that soon, holding it now only because of
https://github.com/google/go-cloud/issues/3472
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
building upon the great work done at #4898closes#4898
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
Co-authored-by: Dylan Myers <dylan.myers@bluemedora.com>
cyclonedx and go.version-m were removed from latest ko version
https://github.com/ko-build/ko/pull/1333
---------
Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
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... -->
...
<!-- Why is this change being made? -->
Even though `^\.?(\.\/[^\/]?.*)?$` was matching with `./cmd/main.go`, I
spent ~10m to figure this out why it was complaining. And noticed that,
we were returning the same error on different case, which is `HasSuffix`
check. Let's clarify the error message a bit for better UX.
<!-- # Provide links to any relevant tickets, URLs or other resources
-->
...
Signed-off-by: Furkan <furkan.turkal@trendyol.com>
Adds code to expose the ipk configuration values and registers the ipk
package format with nfpm.
Updates the documentation with how to use the new ipk specific
configuration parameters.
**This isn't ready to merge, but I have some questions**
1. I copied the `TestIPKSpecificConfig()`
([code](https://github.com/goreleaser/goreleaser/compare/main...schmidtw:goreleaser:main#diff-912a4af69daf4d89537b6bea43a1b7fe65683128ea1be66d6ec77046c76d064dR1358))
from the `TestAPKSpecificConfig()` and found it only is really testing
if specific scripts are there or not. Since IPK doesn't have any
additional scripts, just fields in one file do I need this test
function? Is there a better way to validate the output?
2. I have run into issues where the tests expect `goreleaser` to be the
org & repo - is there a way to override this in my fork without changing
the code?
3. Is the `ToNFPAlts()` and `ToNFP()` living in the config.go file ok?
There wasn't much code in that file, so I figured I'd ask if you'd
rather this code be elsewhere.
---------
Co-authored-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
this bug comes and goes every couple of versions it seems.
this will change the snapcraft implementation to run the first item
without concurrency, so all needed shared directories can be created
without issues, and then grows the limit of the wait group so the other
ones can run in parallel.
I haven't tested this yet, but I think it'll work.
- [x] test
- [x] godoc
refs https://github.com/goreleaser/goreleaser/issues/1715 refs
https://bugs.launchpad.net/snapcraft/+bug/1889741
It has no effect if the release is a draft, and seems to be ignored
later when published.
Move setting the discussion category to the publish method only.
Closes https://github.com/orgs/goreleaser/discussions/4902
