gofr-dev
typos
- chore: rename file with typo in it
- fix: typos in documentation and code
- ci: add typos detection in GitHub actions
Fixes #1666
- #1666
It's funny CI caught the exact example that was added to CONTRIBUTING via https://github.com/gofr-dev/gofr/commit/d3716681e01753e6dd5555c9bddab6ac5643b54f that @Omar8345 added for
- https://github.com/gofr-dev/gofr/pull/1678
I made changes to avoid this
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 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:
websiteworkflow is only called with something is tagged. So it's too late to catch thingsgoworkflow 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:
websiteworkflow is only called with something is tagged. So it's too late to catch thingsgoworkflow 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.
As discussed here, and then on Discord in DM with @Umang01-hash , the current workflows files cannot help us. The main raison are that:
websiteworkflow is only called with something is tagged. So it's too late to catch thingsgoworkflow is not called when the documentation is updated via a PRHey @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.
As discussed here, and then on Discord in DM with @Umang01-hash , the current workflows files cannot help us. The main raison are that:
websiteworkflow is only called with something is tagged. So it's too late to catch thingsgoworkflow is not called when the documentation is updated via a PRHey @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.
As discussed here, and then on Discord in DM with @Umang01-hash , the current workflows files cannot help us. The main raison are that:
websiteworkflow is only called with something is tagged. So it's too late to catch thingsgoworkflow is not called when the documentation is updated via a PRHey @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.