Link and Spell checker Gihub Actions #157
Open
+157
−17
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
…king for things other than html files for documentation deployment
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.
PR for spell check and link check github actions.
The link checker used performs (what I believe) is recursive checking through the compiled documents (since Eric mentions in this issue that lychee is not recursive). I found this specific checker by looking through the link checkers listed in this table generated by lychee.
The [spell checker used] (https://github.com/tbroadley/spellchecker-cli) is based off my list in the original issue. I don't remember the reasons for the order of the list, but if this does not serve us as well down the line, there are other options to look into.
Both actions are listed in one yml to be grabbed by the deployment action after the build step. I'm not sure if the move is to keep it as is, or move the build step to its own file to be called by the deploy action. I think it would be good for this check action to be run with every PR and / or deployment because it doesn't hurt.