When the build argument ZITI_TUNNEL is unset, the fetch-github-releases.sh fails during execution with an unbound variable exception. This is due to strict mode, and because there's no handling for the unbound variable, we never see the friendly Error message.
Here's the original code:
for var in GITHUB_BASE_URL GITHUB_REPO ZITI_VERSION; do
if [ -z "${!var}" ]; then
echo "ERROR: ${var} must be set when fetching binaries from GitHub." >&2
exit 1
fi
done
When building the container image, this results in the following error:
I've tested on my side and confirmed the only required change to catch seems to be adding the :- operator into the IF expression so the variable will default to null if it doesn't exist.
Revised code:
for var in GITHUB_BASE_URL GITHUB_REPO ZITI_VERSION; do
if [ -z "${!var:-}" ]; then
echo "ERROR: ${var} must be set when fetching binaries from GitHub." >&2
exit 1
fi
done
Now the error looks like it should:
=> ERROR [fetch-ziti-artifacts 6/6] RUN bash ./fetch-github-releases.sh ziti-edge-tunnel 0.3s
------
> [fetch-ziti-artifacts 6/6] RUN bash ./fetch-github-releases.sh ziti-edge-tunnel:
#13 0.271 Fetching from GitHub.
#13 0.271 ERROR: ZITI_VERSION must be set when fetching binaries from GitHub.
------
executor failed running [/bin/sh -c bash ./fetch-github-releases.sh ziti-edge-tunnel]: exit code: 1
Alternatively you could specify a default ZITI_VERSION to the latest tag perhaps.
For those still with me...it's worth noting I've seen this issue in the docker-entrypoint.sh as well...and numerous issues where text isn't piped to stderr on failures. I'll raise separate issues for them but something to keep an eye out for when running in strict mode.
When the build argument ZITI_TUNNEL is unset, the fetch-github-releases.sh fails during execution with an unbound variable exception. This is due to strict mode, and because there's no handling for the unbound variable, we never see the friendly Error message.
Here's the original code:
When building the container image, this results in the following error:
I've tested on my side and confirmed the only required change to catch seems to be adding the
:-
operator into the IF expression so the variable will default to null if it doesn't exist.Revised code:
Now the error looks like it should:
Alternatively you could specify a default ZITI_VERSION to the latest tag perhaps.
For those still with me...it's worth noting I've seen this issue in the docker-entrypoint.sh as well...and numerous issues where text isn't piped to stderr on failures. I'll raise separate issues for them but something to keep an eye out for when running in strict mode.