Error setting up jsonnet doesn't fail the task

[dballweg]

We use this action in our repo, and today I got a failure on my action because jsonnet wasn't found in the path. Then I looked into this step and found the error pasted below, but github thinks the step passed (terminated with exit code 0 instead of failing)

Can we look into making this fail when it didn't really setup jsonnet?

Run zendesk/setup-jsonnet@v7 /home/runner/runner/agent/_work/_actions/zendesk/setup-jsonnet/v7/install-jsonnet.sh

• go get github.com/google/go-jsonnet/cmd/jsonnet unrecognized import path "gopkg.in/yaml.v2": reading https://gopkg.in/yaml.v2?go-get=1: 502 Bad Gateway server response: Cannot obtain refs from GitHub: cannot talk to GitHub: Get https://github.com/go-yaml/yaml.git/info/refs?service=git-upload-pack: net/http: request canceled (Client.Timeout exceeded while awaiting headers) (node:4495) UnhandledPromiseRejectionWarning: Error: The process '/home/runner/runner/agent/_work/_actions/zendesk/setup-jsonnet/v7/install-jsonnet.sh' failed with exit code 1 at ExecState._setResult (/home/runner/runner/agent/_work/_actions/zendesk/setup-jsonnet/v7/node_modules/@actions/exec/lib/toolrunner.js:574:25) at ExecState.CheckComplete (/home/runner/runner/agent/_work/_actions/zendesk/setup-jsonnet/v7/node_modules/@actions/exec/lib/toolrunner.js:557:18) at ChildProcess. (/home/runner/runner/agent/_work/_actions/zendesk/setup-jsonnet/v7/node_modules/@actions/exec/lib/toolrunner.js:451:27) at ChildProcess.emit (events.js:210:5) at maybeClose (internal/child_process.js:1021:16) at Socket. (internal/child_process.js:430:11) at Socket.emit (events.js:210:5) at Pipe. (net.js:659:12) (node:4495) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:4495) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[newhoggy]

I've found that downgrading to v6 can help.