Description
[DEBUG] A DSBC stage running on node 'nutci-debian-11-amd64' requested for stage 'MATRIX_TAG="gnu11-gnu++11-gcc-10-debian11-x86_64-64bit-nowarn" && (ARCH_BITS=64&&ARCH64=x86_64&&COMPILER=GCC&&GCCVER=10&&OS_DISTRO=debian11&&OS_FAMILY=linux) && (nut-builder) && BITS=64&&CSTDVARIANT=gnu&&CSTDVERSION_c=11&&CSTDVERSION_cxx=11 && LANG=C && LC_ALL=C && TZ=UTC && BUILD_TYPE=default-all-errors && BUILD_WARNFATAL=yes && CI_BUILDDIR=obj && BUILD_WARNOPT=hard' :: as part of slowBuild filter: GNU C standard out-of-tree builds with fatal warnings with GCC, without distcheck and docs (must pass) completed with an exception: Got a Throwable not classified specifically: Message: Could not checkout 5ab73072a6f320ff30e84493eafc94b6822df909; Cause: hudson.plugins.git.GitException: Command "git checkout -f 5ab73072a6f320ff30e84493eafc94b6822df909" executed in workdir "/home/abuild/jenkins-nutci-debian-11-amd64/workspace/nut_nut_PR-1984@3" returned status code 128: stdout: stderr: fatal: reference is not a tree: 5ab73072a6f320ff30e84493eafc94b6822df909 ; toString: (hudson.plugins.git.GitException: Could not checkout 5ab73072a6f320ff30e84493eafc94b6822df909)
Here the source branch for the PR was force-pushed and apparently the commit involved (original or ephemeral as PR+HEAD merge?) became no longer available despite all the stash preparation and dissemination involved. One of the goals of that stashing feature was to have started builds survive independently of GitHub platform and content availability, so at least a retry to handle such hiccups differently should be on the plate...
https://ci.networkupstools.org/job/nut/job/nut/job/PR-1984/5/
What's "worse" however, seems this situation weirdly impacted the verdict accounting:
Running 149 'slow build' dynamatrix stages
Not all went well: countStagesStarted:149 countStagesCompleted:148 countStagesFinishedOK:148
That one scenario is listed as a FAILURE (1) but there is no specific verdict like countStagesFinishedFailure or countStagesAborted logged for it. I guess this got recorded as UNKNOWN internally and those are not reported in the detailed pretty print-outs. At the very least, it (probably) did not end up in countStagesCompleted either.
Wondering if this is a fall-out of #18 or not...