Yeah, that’s what I did. Force pushing Whack-a-Moled the “reference is not a tree” failure over to a different job in the next run.
Best guess is that there’s a cached version of the repo in some GitHub endpoint. After a force push, the workflow kicks off immediately with the SHA of the new head, but the repo cache may not be updated when the Jenkins runner tries to fetch that SHA.
GitHub’s own workaround for this (in their actions/checkout) is to retry up to three times, randomly delaying 10-20 seconds after each failure, for git fetch and git ls-remote.
Again, probably no action necessary, unless these failures become frequent. (Just wanted to report the issue somewhere, in case others are seeing it.)