This is the workflow, roughly as I used it to develop the PR, but with a couple of changes.
As configured check-spelling will produce a job summary reachable via Details.
When possible, it will generate a Sarif report, and if a user is an admin (or nearly an admin) they'll be able to view it in GitHub, otherwise, users can download a generated artifact and process w/ their own tools (especially VSCode).
I've configured it to provide a fallback message (using spell_check_this: memgraph/orb@main) (ideally this shouldn't be necessary, but I think I have a bug I need to resolve which I haven't had time to focus on) -- note that this assumes it'll be merged to main before most people notice the workflow.
The advice.md file is a markdown file that the project can customize based on the needs of its maintainers/contributors. The README.md is designed to be helpful documentation, but is absolutely optional.
You'll want to review expect.txt at least once, and potentially periodically (depending on how good people are at paying attention to the tool -- at work people sometimes just accept its suggestions even when it's pointing out obvious typos 🤷♂️).
The update job is designed to only run in forks (see https://github.com/check-spelling/tac/pull/3 for an example of it refusing to run in the configured repository -- sorry, I'm recycling some text, but the same would apply for this workflow...). It enables people to talk to their own instance instead of running the update command locally / manually editing expect.txt / excludes.txt. You're encouraged to play with this logic in a fork, or if you aren't comfortable with it, there's nothing wrong with omitting the job.
It's using the latest released tag (v0.0.21). Some projects are release-early / release-often -- check-spelling isn't. I don't tend to make a lot of releases although my coworkers are dogfooding prerelease in a dozen repositories (and I'm constantly dogfooding it to make contributions such as the one that was merged here). If you start using GitHub workflows, you'll want to set up dependabot to make PRs for updates to things.
I'm happy to answer questions here / in Discord, and if this is merged, I'll probably watch the repository for a bit to make sure people don't have any problems.
In https://github.com/memgraph/orb/pull/65#pullrequestreview-1530067792, @tonilastre suggested adding the check-spelling workflow.
This is the workflow, roughly as I used it to develop the PR, but with a couple of changes.
As configured check-spelling will produce a job summary reachable via Details.
When possible, it will generate a Sarif report, and if a user is an admin (or nearly an admin) they'll be able to view it in GitHub, otherwise, users can download a generated artifact and process w/ their own tools (especially VSCode).
I've configured it to provide a fallback message (using
spell_check_this: memgraph/orb@main) (ideally this shouldn't be necessary, but I think I have a bug I need to resolve which I haven't had time to focus on) -- note that this assumes it'll be merged to main before most people notice the workflow.The
advice.mdfile is a markdown file that the project can customize based on the needs of its maintainers/contributors. TheREADME.mdis designed to be helpful documentation, but is absolutely optional.You'll want to review
expect.txtat least once, and potentially periodically (depending on how good people are at paying attention to the tool -- at work people sometimes just accept its suggestions even when it's pointing out obvious typos 🤷♂️).The update job is designed to only run in forks (see https://github.com/check-spelling/tac/pull/3 for an example of it refusing to run in the configured repository -- sorry, I'm recycling some text, but the same would apply for this workflow...). It enables people to talk to their own instance instead of running the update command locally / manually editing
expect.txt/excludes.txt. You're encouraged to play with this logic in a fork, or if you aren't comfortable with it, there's nothing wrong with omitting the job.It's using the latest released tag (v0.0.21). Some projects are release-early / release-often -- check-spelling isn't. I don't tend to make a lot of releases although my coworkers are dogfooding prerelease in a dozen repositories (and I'm constantly dogfooding it to make contributions such as the one that was merged here). If you start using GitHub workflows, you'll want to set up dependabot to make PRs for updates to things.
I'm happy to answer questions here / in Discord, and if this is merged, I'll probably watch the repository for a bit to make sure people don't have any problems.