Autoresolve cspell GIT_DEPTH issue when diff fails

Another sample:
https://git.drupalcode.org/issue/drupal-2293803/-/jobs/855982
(Visual count is ~63 commits above latest 11.x)

If we do go with the 2nd option I would suggest choosing whatever has been the largest issue ever seen x3 for the safety factor (at the moment that would be ~220)

$ if [ -n "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA" ]; then echo "HEAD is $(git rev-parse HEAD). \$CI_MERGE_REQUEST_TARGET_BRANCH_SHA is ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA}"; else echo "HEAD is $(git rev-parse HEAD). \$CI_MERGE_REQUEST_DIFF_BASE_SHA is ${CI_MERGE_REQUEST_DIFF_BASE_SHA}"; fi;
HEAD is d59b4737d20111a48d875bf1deb6b4b813a3556a. $CI_MERGE_REQUEST_DIFF_BASE_SHA is 71c9b9f7cdaf3ac42d05450627dff82c2e847e1c
$ git diff ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA:-$CI_MERGE_REQUEST_DIFF_BASE_SHA} --name-only | sed "s_^_../_" | yarn --cwd=./core run -s spellcheck:core --no-must-find-files --file-list stdin
fatal: bad object 71c9b9f7cdaf3ac42d05450627dff82c2e847e1c
CSpell: Files checked: 0, Issues found: 0 in 0 files

Another one.

https://git.drupalcode.org/issue/drupal-3100732/-/pipelines/151703

Ran into this, puzzlinig me. Ended up doing an interactive rebase to minimize the amount of commits, but that really feels like a waste of time.

On failure trying to do a pull/fetch for these circumstances sounds like a good idea tbh. Keep the performance, and go deeper where needed.

This is blocking CI here: https://git.drupalcode.org/issue/drupal-1792310/-/jobs/1725958

What is this limit supposed to achieve?

This pipe is the broken one: https://git.drupalcode.org/issue/drupal-3422537/-/pipelines/187980

Will now try and fix with git command.

This job fixed here: https://git.drupalcode.org/issue/drupal-3422537/-/jobs/1746948

using the following command:

git diff ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA:-$CI_MERGE_REQUEST_DIFF_BASE_SHA} --name-only 2>1 > /dev/null || echo "Warning, cannot find changed files converting to full clone." & (git fetch --unshallow --quiet && echo "Fetch successful.")

1. If git diff ${CI_MERGE_REQUEST_TARGET_BRANCH_SHA:-$CI_MERGE_REQUEST_DIFF_BASE_SHA} --name-only 2>1 > /dev/null fails
2. echo echo "Warning, cannot find changed files converting to full clone." and run:
3. (git fetch --unshallow --quiet && echo "Fetch successful.") to unshallow the fir repository without to much noise.

:)

MR 8259: testing MR to proove the issue.
MR 8258: The change for core :)

bbrala → credited dww → .

bbrala → credited longwave → .

Credits.

Logic is flawed, always fetches.

Fixed with extra (). All ready.

Even if it's a stop gap until an even better solution comes up, this would be great to get in. Nice work @bbrala

Oh, the irony! 🤣

https://git.drupalcode.org/issue/drupal-3422537/-/jobs/1747113

Issues found:
./.gitlab-ci.yml:404:202 - Unknown word (unshallow)
CSpell: Files checked: 1, Issues found: 1 in 1 file.

Anyway https://git.drupalcode.org/project/drupal/-/merge_requests/8258/diffs looks excellent. That's more or less exactly what I had in mind.

I'm not totally following the results in https://git.drupalcode.org/project/drupal/-/merge_requests/8259/pipelines to see that this definitely fixes the problem. But on first principles, the merge-able MR (!8258) looks right, and based on the history of these failures and what we understand about their cause, it should solve it.

Super minor cost to run git diff twice, and that avoids always doing a full clone (which would be much more costly).

Ship it! 😉

Thanks,
-Derek

To be clear @dww the secondary mr fails on spellcheck first, same issue as in is. Then later it fails on a true spelling error. Which mean spellcheck works. :)

Ahhh, gotcha. Thanks for explaining.

ed1e913d2bb2fb6c3a469a09a26d1ae575746e99 looks fine -- not even a "typo" really, only adding a , to the warning message to improve legibility.

Definitely still RTBC. Let's get this in.

Thanks again!
-Derek

Committed e51adec and pushed to 11.x. Thanks!
Committed 6b1054d and pushed to 11.0.x. Thanks!
Committed and pushed 7821e759a1 to 10.4.x and 96cf406d48 to 10.3.x. Thanks!

The big issues in the queue thank you ;)

Automatically closed - issue fixed for 2 weeks with no activity.