infra/linters: Replace spellcheck with Typos

[Alex-deVis]

Prerequisite Checklist

• Read the contribution guidelines regarding submitting new changes to the project;
• Tested your changes against relevant architectures and platforms;
• Updated relevant documentation (if needed).

Description of changes

Spellcheck is difficult to maintain because it complains about every unknown word, including technical terms, acronyms, and names.

Typos is a more relaxed spellchecker, which only complains about common misspellings and lets the user handle new words such as the previous examples. The configuration in .github/.typos.toml allows ignoring strings that match regexes, so we have a nice way of handling command outputs.

Additionally, our approach does not scale - the actions repo has 64 PRs that add new words. It is cumbersome to ask a contributor to add common technical terms for each contribution.

[teodutu]

Let's give it a shot. It can't be worse than spellcheck. Also add it to the actions repo [1] if it proves useful.

But can you run it locally?

[1] https://github.com/open-education-hub/actions

[Alex-deVis]

@teodutu I rebranded this to add Typos instead of misspell. I tested it locally and got some nice results - check the changed files. The downside is that there is no out-of-the-box docker image to run this locally but we can create our own.

[teodutu]

Add a lint rule to the Makefile that runs this linter locally.

[teodutu]

Ina addition, you'll have to add exceptions for what's causing typos to fail now and fix the other linter errors.

[teodutu]

Also, the super-linter errors do make sense. Fix them: https://github.com/cs-pub-ro/operating-systems/actions/runs/12534993042/job/34956380764?pr=153

[Alex-deVis]

The checkpatch action will be fixed once open-education-hub/actions#100 is merged. The errors in superlinter are false positives.

[teodutu]

That one super-linter error is acutally bullshit. You can ignore it inline AFAIK, right?

[Alex-deVis]

That one super-linter error is acutally bullshit. You can ignore it inline AFAIK, right?

No, you need to define a CPPLINT.cfg in that directory, which will overwrite the CPPLINT.cfg in the repo root.

The [build/include_what_you_use] error appears for a lot of our source files and always complains about not including string.h even though the sources compile. Since we are testing changes (mostly in production), missing imports will not be a problem, so I would rather remove this rule than having PRs falling over this.

For concrete examples, checkout #150 and remove the [build/include_what_you_use] line from the root CPPLINT.cfg.

What do you suggest, we ignore it globally or tackle it as we go?

[teodutu]

Ok now removing it in #150 makes sense. It seems this check spits false positive errors when encountering the string string :)))).