CI: add typos-action to GHA

[ccoVeille]

• chore: rename file with typo in it
• fix: typos in documentation and code
• ci: add typos detection in GitHub actions

Fixes #1666

• Set up a typo detectors, focused on American English #1666

It follows

• document use of American English in CONTRIBUTING.md #1678
• Document American English is preferred in CONTRIBUTIONS.md #1667

[ccoVeille]

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

[ccoVeille]

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

[Omar8345]

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

[ccoVeille]

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.

[ccoVeille]

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

cc @Omar8345 if you are curious

[ccoVeille]

@Umang01-hash @vikash @coolwednesday @aryanmehrotra

Is there anything blocking with thie PR?

[Omar8345]

@ccoVeille nice catch for this issue, all the best

[Umang01-hash]

@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.

[ccoVeille]

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

[Umang01-hash]

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.

[ccoVeille]

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

[coolwednesday]

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.

[coolwednesday]

#1679 (comment)

[ccoVeille]

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.

That's one way, indeed. I'm fine with doing the following changes, if two people confirm me they are OK with the following plan:

• include typos detection as a job in the file currently named go.yml
• update all jobs currently in go.yml to exclude docs/ path
• prefix all jobs currently in go.yml to mention they are about Go
• rename go.yml workflow with another name (maybe code.yml)

I can do it, but for me, there is no logic in keeping the number of workflow low.

And here these changes are pretty important for almost no gain.

That said, if there is a consensus in such need, I can do it.

[Umang01-hash]

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.

That's one way, indeed. I'm fine with doing the following changes, if two people confirm me they are OK with the following plan:

• include typos detection as a job in the file currently named go.yml
• update all jobs currently in go.yml to exclude docs/ path
• prefix all jobs currently in go.yml to mention they are about Go
• rename go.yml workflow with another name (maybe code.yml)

I can do it, but for me, there is no logic in keeping the number of workflow low.

And here these changes are pretty important for almost no gain.

That said, if there is a consensus in such need, I can do it.

@coolwednesday I think what @ccoVeille suggested is right. Doing all the above changes just at cost of not making new workflow maybe isn't the best idea.

[coolwednesday]

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.

That's one way, indeed. I'm fine with doing the following changes, if two people confirm me they are OK with the following plan:

• include typos detection as a job in the file currently named go.yml
• update all jobs currently in go.yml to exclude docs/ path
• prefix all jobs currently in go.yml to mention they are about Go
• rename go.yml workflow with another name (maybe code.yml)

I can do it, but for me, there is no logic in keeping the number of workflow low.
And here these changes are pretty important for almost no gain.
That said, if there is a consensus in such need, I can do it.

@coolwednesday I think what @ccoVeille suggested is right. Doing all the above changes just at cost of not making new workflow maybe isn't the best idea.

Sure, I was suggesting a way around to have it in the same workflow. It is a lot of unnecessary work, indeed. So I do not have problem with the current implementation.