Fix weekly sweep masking the conflict-check exit code#271
Merged
Conversation
The full-file check piped through `tee`, but the step ran under the default `bash -e` shell without pipefail, so the pipeline took tee's exit code (0) and the failing check was reported as success. This is the same silent-failure class the check itself was meant to catch: the manual dispatch printed the id-88 conflict yet the job passed and no issue was filed. Set `shell: bash` so the step runs with pipefail.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The weekly board conflict sweep was reporting success even when the check found a conflict. The check step pipes the script through
teeto capture its output for the issue body, but the step ran under the defaultbash -eshell, which does not setpipefail. Without it the pipeline takestee's exit code (0), so the script'sexit 1was swallowed and the job passed.This is the same silent-failure class the check was built to catch. The manual dispatch right after merge made it obvious: the log printed
Conflict detected: Value "88" ...andERROR: 1 board ID conflict(s) detected, yet the job concluded success, theReport failurestep was skipped, and no tracking issue was filed.The fix sets
shell: bashon the step, which GitHub runs with-o pipefail, so the script's exit code is no longer masked bytee. After this lands, a re-dispatch should fail on the existing id-88 conflict and open the tracking issue as intended.