GoReleaser
CI builds fail due to Gumroad 500s #6380
Replies: 2 comments 16 replies
-
|
ouch, first of all, sorry - that's definitely bad. I will contact their support, if for nothing else, to complain about it. Also, I've been thinking about doing air-gapped licensing for a while now, might experiment with something similar to what keygen.sh does (a signing certificate with metadata, probably valid until next payment). |
Beta Was this translation helpful? Give feedback.
-
|
Happy to get you onboarded onto Keygen Cloud, or you can self-host CE if that works better for you! Easy to wire up Gumroad <> Keygen with Zapier: https://zapier.com/apps/keygen/integrations/gumroad. Let me know if I can help at all. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah then all we would have to ensure is that we update our build environment with that new binary or license file or whatever the artifact is once a year. That is a lot better than making API calls on every build, which has been called out to the team and now my leadership is looking for us to address this. |
Beta Was this translation helpful? Give feedback.
-
|
Nightly build going out right now with It's on a very beta stage right now, so I'm very open to suggestions and changes until the next release. Let me know what you think. |
Beta Was this translation helpful? Give feedback.
-
|
After testing, I’m fine with the 90-day option — but only if we can point GoReleaser at a license file directly, instead of having to cat the contents into an env var. Ideally something like: GORELEASER_KEY_FILE=/path/to/goreleaser.keyThat would let us bake the exported license into the image and just reference the path from the Dockerfile. Docker can’t set an Example: # Check for updates here: https://github.com/goreleaser/goreleaser-pro/releases
ARG GORELEASER_LICENSE_KEY
ENV GORELEASER_VERSION="2.14.0"
RUN set -ex \
&& curl -fsSLo "goreleaser.tar.gz" "https://github.com/goreleaser/goreleaser-pro/releases/download/${GORELEASER_VERSION}/goreleaser-pro_Linux_x86_64.tar.gz" \
&& tar -xvf "goreleaser.tar.gz" -C "/usr/local/bin" goreleaser \
&& rm -rf goreleaser.tar.gz \
&& goreleaser license-export --key "${GORELEASER_LICENSE_KEY}" -o /goreleaser.key
ENV GORELEASER_KEY_FILE=/goreleaser.key |
Beta Was this translation helpful? Give feedback.
-
|
ah sounds good, will patch! |
Beta Was this translation helpful? Give feedback.
-
|
pushed and new nightly underway |
Beta Was this translation helpful? Give feedback.
-
|
Yep that change works. For others implementing this with air gapped networks you will need to allow list: https://cfw.goreleaser.com/api/v1/license/export. Also the env var is still |
Beta Was this translation helpful? Give feedback.
-
|
yes, the exporter would need access to that URL. Thanks for the suggestions and for testing, @ryancurrah ❤️ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We’re seeing CI builds fail because GoReleaser Pro requires a Gumroad API call during builds, and Gumroad occasionally returns 500s. This makes our CI non-deterministic and creates an unacceptable external failure point for release pipelines.
Related: #4371
Examples (Gumroad 500 during build):
We want to keep using and paying for GoReleaser Pro, but we need a distribution/auth mechanism that doesn’t require a live third-party API call on every build.
Is there a supported option (or roadmap) for any of these?
The core issue for us is CI reliability: builds should not fail because Gumroad is down.
Beta Was this translation helpful? Give feedback.
All reactions