This should help from now to avoid typos in code and documentation.

It's funny CI caught the exact example that was added to CONTRIBUTING via d371668 that @Omar8345 added for

• document use of American English in CONTRIBUTING.md #1678

I made changes to avoid this

@ccoVeille how funny - the CI definitely overdid its job here! 😂

I convert it back to draft, as I have a few changes to do.

It would help, and I need to fix a few things, instead of disabling words like "typ" and "ba", that detects real typo

I don't want this PR to be merged yet.

Code is now ready to be reviewed, and merged if accepted like this

cc @Omar8345 if you are curious

@Umang01-hash @vikash @coolwednesday @aryanmehrotra

Is there anything blocking with thie PR?

@ccoVeille nice catch for this issue, all the best

@ccoVeille the PR looks good to me.
One minor suggestion is can we run this typo's job parallel to our other jobs instead of a new workflow. This way we can complete all the checks in a single workflow run.

One minor suggestion is can we run this typo's job parallel to our other jobs instead of a new workflow. This way we can complete all the checks in a single workflow run.

I'm afraid I don't understand the point.

Here is my understanding of the GitHub CI via GHA

• all workflows are run in parallel, there is no logic of ordering
• all jobs in a workflow are run in parallel
• steps are run sequentially in a job

Right now, there are two workflows:

• one for the website (only for when a release is tagged)
• one for the code (docs/ is excluded)

I set up the typos workflows in a way typos detection is launched only once, in a way one PR containing one typo in the code and one typo in the documentation will lead to one job failing and not two, to make it easier to follow.

Maybe I don't understand what you meant,
so please let me know if it's clearer

One minor suggestion is can we run this typo's job parallel to our other jobs instead of a new workflow. This way we can complete all the checks in a single workflow run.

I'm afraid I don't understand the point.

Here is my understanding of the GitHub CI via GHA

• all workflows are run in parallel, there is no logic of ordering
• all jobs in a workflow are run in parallel
• steps are run sequentially in a job

Right now, there are two workflows:

• one for the website (only on docs/)
• one for the code (docs/ is excluded)

I set up the typos workflows in a way typos detection is launched only once, in a way one PR containing one typo in the code and one typo in the documentation will lead to one job failing and not two, to make it easier to follow.

Maybe I don't understand what you meant, so please let me know if it's clearer

@ccoVeille I meant to say let's add it as a step in existing workflow.

As discussed here, and then on Discord in DM with @Umang01-hash , the current workflows files cannot help us.

The main raison are that:

• website workflow is only called with something is tagged. So it's too late to catch things
• go workflow is not called when the documentation is updated via a PR

As discussed here, and then on Discord in DM with @Umang01-hash , the current workflows files cannot help us.

The main raison are that:

• website workflow is only called with something is tagged. So it's too late to catch things
• go workflow is not called when the documentation is updated via a PR

Hey @ccoVeille , I would suggest having the docs ignore filter added in each job, instead of at the very start of the workfkow file. In that case you would be able to control what jobs should run how.