CSpell checks files that are created by a GitLab CI job

Hi avpaderno,
Thanks for raising this following this slack thread. You are right that we should not be including the internal files when checking spelling.

One very quick and simple way to fix this is to add the get-file-via-curl.sh file into the $ignore_files array in scripts/prepare-cspell.php.

But the problem stems from the fact that we run cspell from the top-level build directory $CI_PROJECT_DIR (which is /builds/project/seven in this case). We are already having to ignore "$webRoot", 'vendor', 'node_modules' and some other files such as 'build.env'. A more robust solution would be to run the cspell job in the Drupal project folder $DRUPAL_PROJECT_FOLDER (which is /builds/project/seven/web/themes/custom/seven in this case). Here we do not have the extra scripts and scaffolding folders, so it would be a cleaner way to execute the job.

There may be a good reason why this was not done in the first place, or it may have been investigated and rejected, so I can't say for ceertain that we can do this, but it is worth investigating.

I think the$DRUPAL_PROJECT_FOLDER was just introduced later than the latest changes we did in cspell job.

We can either add the internal file to our ignore list for cspell or just try to run cspell on the $DRUPAL_PROJECT_FOLDER folder directly.

Probably, also the assets/internal/.cspell.json file needs to be updated. Its ignorePaths value could be changed, although I would consider a project repository can contain a node_modules or a vendor directory.

Thanks for opening the MR. I've made a couple of suggestions following the failed cspell jobs. I also pushed changes to not run all the unwanted jobs and variants. But I will leave the actual cspell work for you to continue on.

I think the $DRUPAL_PROJECT_FOLDER was just introduced later than the latest changes we did in cspell job.

Yes the variable is new, but we did do earlier work to run eslint, phpstan and styleliny in the lower-level folder, before we had the variable.

Another angle to try might be to run cspell where it is now, but specify $DRUPAL_PROJECT_FOLDER as the path to check in. This would only involve changing the value of $CSPELL_SEARCH or maybe pre-pending the path to it in the execution call.

I guess it makes sense to do the cd $DRUPAL_PROJECT_FOLDER to match what the other jobs do. We might have just forgotten about cspell when we did the change.

NW based on your suggestions.

We might have just forgotten about cspell when we did the change

I don't think we forgot, as it was not an overall review of every job and where they execute. We were fixing things as and when the problems occured. Yes, lets try the cd way first.

Whilst we are working on cspell, another feature that I've been wanting, and which would really help in testing this MR, is the ability to have the hard-coded --no-progress in the command. It should be a variable, which defaults to hiding the progress to maintain the current behavior, but can be set when doing testing like this, so that we see a list of the files being checked. Maybe it could be called CSPELL_SHOW_PROGRESS or CSPELL_VERBOSE or something. It defaults to 0 but can be set to 1 if required. Then the progress setting would be simply derived, in a similar way to what we do for CSPELL_SEARCH

I've run the downstream pipelines for d9-basic and d10-theme for you (this can only be done by a maintainer of the downstream project). Also left another comment in the MR. The two jobs fail for different reasons, which is interesting and needs a closer look at.

Thanks for adding the verbose flags. I've run the downstream job, and we still get CSpell: Files checked: 0, Issues found: 0 in 0 files. I think this is because cspell cannot work with symlinked files, and I have just tested this locally and that is exactly what is happening. I get the same message, when all the files are symlinked. But if I create a new non-symlink file it gets checked.

So that means the whole approach of cd $DRUPAL_PROJECT_FOLDER needs to be undone, as we cannot run the command there. We will use the other approach (as mentioned in #2 and #3 above) to add the script name into the $ignore_files array.

Let me know if you still want to do this MR, you just need to revert the path changes in the cspell: section (but leave in the --progress change and the skip_ variables for now). Then you'll nee to make a change to prepare-cspell.php to add the .sh script name. Or if you do not want to do all this, that's fine, just say and we can pick it up instead. It's great having others collaborate on Gitlab Templates but equally there's no pressure to continue, just say.

cspell cannot work with symlinked files

That might have been the reason why the approach on this job was different to the others.

100% agree with #15 about reverting and trying the other approach (and 100% on the grateful-but-no-pressure part too).

We should definitely add a comment by that cd saying this job has to run in the top-level folder because cspell does not work with symlinked files. When I saw the "0 files checked" I had a vague recollection that we did know this once upon a time.