travis: skip check patch when shallow cloning makes the PR "infinite" #2543
Conversation
When "back-merging" upstream Linux into our shallow target branch, "git rev-list" can fail to reconnect the bottom of our shallow clone with upstream Linux. In such a case the shallowness makes git rev-list wrongly believe that the list of new commits submitted in the pull request is the entire git history since the dawn of time. Try to detect such backmerges and skip checkpatch when we find one. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
marc-hb
requested review from
bardliao,
dbaluta,
lgirdwood,
plbossart and
ranj063
as code owners
|
I would actually like to split the 'age of branch' from the 'checkpatch'. Those are different results, and I don't like having to scroll to figure out which of the two is a problem. |
OK, in that case I think I should drop the very time consuming "unshallow" for the "age of branch" test and unshallow only for checkpatch (which really needs a merge-base for normal PRs). This means the age test will fail faster and show less data: not showing how far ahead the sof-dev target branch is when more than depth=20 patches get merged to sof-dev. In that case maybe depth should be increased a bit, say to 30? How long are patch series merged to sof-dev typically? UPDATE: this entire situation is actually very complicated. Don't quote any of this above and stay tuned. |
|
@marc-hb I don't think I've seen a PR case with 30 patches (or it was draft code with tons of dependencies on other trees). I may have done some cleanups with a lot of patches as well, I think at some point I may have had 70 patches, but small ones really. |
As requested in fix for checkpatch issue PR thesofproject#2543 which will be rebased on top of this. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
|
closing since there was no update and it's not clear if Travis is still relevant. |
marc-hb
requested review from
cujomalainey,
kv2019i,
lyakh,
nashif,
paulstelian97,
sofci and
xiulipan
|
The long story short: shallow cloning can cause git to report that some pull requests have 1 million commits (all commits since the start of the repo). See demo in #2556. Until some git guru finds a workaround for #2556, this means shallow cloning is not compatible with checkpatch or any other tool that looks at the git history. In practice this affects only large and complex repos like the Linux kernel. This issue is totally unrelated to Travis and affects any CI exactly the same. The most obvious solution is to avoid shallow cloning and perform some caching instead. |
3 participants
When "back-merging" upstream Linux into our shallow target branch,
"git rev-list" can fail to reconnect the bottom of our shallow clone
with upstream Linux. In such a case the shallowness makes git rev-list
wrongly believe that the list of new commits submitted in the pull
request is the entire git history since the dawn of time. Try to detect
such backmerges and skip checkpatch when we find one.
Signed-off-by: Marc Herbert marc.herbert@intel.com