hack/ci: do not swallow apiv2 failures - #29528
Open
vtushar06 wants to merge 1 commit into
Open
Conversation
Signed-off-by: Tushar Verma <tusharmyself06@gmail.com>
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 apiv2 bash suite has not gated CI since 66c6da6.
run_apiv2puts both make targets inside onesh -c "( ... )"with noset -e, so only the last command decides the exit status andmake localapiv2-bashis discarded.set -eo pipefailat the top of runner.sh is the outer bash and does not reach into that innersh.It is failing right now on main. Run 31847250452, job
apiv2 rootless fedora-current, conclusion success, log line 3089:Same thing in the three earlier green main runs I checked (31687097967, 31540756565, 31514570842), each with plan
1..2191andError 17.I used an accumulator rather than
set -eso the python half still runs when the bash half fails - otherwise we would lose that half of the report on every failure. Checked the shapes on bash 5.2: the current one exits 0 when the first target fails, this one exits 1 and still runs both.I have not looked into the 17 failures themselves yet, they look like three clusters in 26-containersWait and 27-containersEvents. Happy to open a separate issue for those once this gates again.