Add check-spelling action #67
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #65 (review), @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 check-spelling-sandbox/tac#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.