Our farm's network outage (or rather great lagginess - not outright refusal of connections) caused many empty `git ls-remote` responses during a Poll SCM and/or Branch Indexing scan, which (when seen as a string) do differ from the latest known/built hashes, and so cause rebuild of our world on our CI farm due to "SCM Change":

-------------------------
Polling Log
View as plain text

This page captures the polling log that triggered this build.

Started on Jun 4, 2020 1:43:59 PM
Using strategy: SpecificRevisionBuildChooser
[poll] Last Built Revision: Revision 0001d2d96b880f6457d2534349ffb419d292b98f (master)
using credential 955c217d-8133-41c2-9235-9ce3936ddca6
 > git --version # timeout=10
using GIT_ASKPASS to set credentials GHToken as password
 > git ls-remote -h https://github.com/42ity/fty-certificate-generator-rest.git # timeout=10
Unexpected ls-remote output line ''
[poll] Couldn't get remote head revision
Done. Took 1 min 8 sec
Changes found
--------------------------

leading to:

--------------------------
Build #17 (Jun 4, 2020 1:45:19 PM)

Started by an SCM change

This run spent 9 sec waiting in the queue.
	Revision: 0001d2d96b880f6457d2534349ffb419d292b98f
    master
--------------------------

As discussed on IRC with markewaite, posting the issue here to not get it lost.

The likely course of action is to add a (global? later per-org etc.?) toggle whether to treat the empty-strings, or perhaps anything that is techically not a valid commit hash (strictly or up 32 hex chars?), or any codepath that already leads to logging "Couldn't get remote head revision", as an SCM Change or not.

This toggle would default to current behavior for least surprise (people can prefer and may be used to being on the safe side of rebuilding latest seen code, even if it means doing so several times sometimes) and to avoid new codepaths and interactions that might introduce breakage, but particular deployments can then flip it to not rebuild world (nor record the invalid last-seen commit) due to network hiccups like this, and have such skipping mentioned in their scan-log.