-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CI step "Set toolchain version" can fail without stopping CI job #225
Comments
Hi @joshlf , I would like to try it. |
Hey @zoo868e, sounds good, thanks! Let me know if you have any questions at any point! |
Hello @joshlf, It seems that the issue is arising intermittently, possibly due to a GitHub action facing difficulties in fetching dependencies during the execution of Therefore, I'm interested to know if there is a reliable method to verify whether the issue has been resolved, given that it doesn't occur consistently. The approach that comes to mind for me to assess the issue's current status is to run the CI process multiple times and hope that the problem shows up. Moreover, the failures are consistently caused by difficulties in fetching the Thank you. |
Fixes google#225 The reason `set -e` failed to interrupt the workflow is due to the output redirection to `jq`. Since `jq` returns a value of 0, indicating success, the script continues to execute. You can try running these scripts locally to gain insight into the issue. To illustrate: Script without interruption: ```sh set -e function pkg-meta { cargo metadata --format-version 1 | jq -r ".packages[] | select(.name\ == \"zerocopy\").$1" } ZC_TOOLCHAIN=\"$(pkg-meta 'metadata.ci.\"pinned-nightly\"')\" echo \"Discovered that the nightly toolchain is $ZC_TOOLCHAIN\" echo \"ZC_TOOLCHAIN=$ZC_TOOLCHAIN\" ``` Script with interruption: ```sh set -e function pkg-meta { cargo metadata --format-version 1" } ZC_TOOLCHAIN=\"$(pkg-meta 'metadata.ci.\"pinned-nightly\"')\" echo \"Discovered that the nightly toolchain is $ZC_TOOLCHAIN\" echo \"ZC_TOOLCHAIN=$ZC_TOOLCHAIN\" ``` Additionally, you can display the return value after the command execution. This output will confirm the successful execution of the command. ```sh set -e function pkg-meta { cargo metadata --format-version 1 | jq -r \".packages[] | select(\ .name == \"zerocopy\").$1\" echo echo \$? } ZC_TOOLCHAIN=\"$(pkg-meta 'metadata.ci.\"pinned-nightly\"')\" echo \"Discovered that the nightly toolchain is $ZC_TOOLCHAIN\" echo \"ZC_TOOLCHAIN=$ZC_TOOLCHAIN\" ``` Therefore, I've incorporated `cargo check` to validate the package retrieval. Subsequent to this check, there's no necessity to fetch the package again using `cargo metadata`. This modification should rectify the point of failure in the Git action.
To bolster reliability, incorporate the -o pipefail option, which designates a command pipeline's overall return status as failed if any individual command within it fails. Following this, integrating the -e option can empower the script with the ability to promptly halt execution. Fixes #225
In this CI job, it appears that a network error causes issues with the "Set toolchain version" step, but the GitHub runner does not fail at that point. Instead, later steps are executed with bad data (namely, the
ZC_TOOLCHAIN
environment variable is set to an empty string), causing confusing errors.I suspect that what's happening is that the shell script executed for that step has a bug that results in errors inside of
$(...)
to not respect theset -e
at the top of the script.The text was updated successfully, but these errors were encountered: