krisfreedain
commented
1 year ago thanks @peternied - it's an interesting idea that could even be expanded on. Adding this to the update project.
Open peternied opened 1 year ago
krisfreedain
commented
1 year ago thanks @peternied - it's an interesting idea that could even be expanded on. Adding this to the update project.
nateynateynate
commented
1 year ago @peternied - I believe that Jekyll will treat that metadata as case sensitive. meta_keywords would have done the trick, but not Meta_keywords. When the build process checks for these things, does it run cheecks before or after jeykll produces the html?
I'd love to have some time with you to learn more about how the build process works and what our codecommit infrastructure looks like.
Ping me sometime?
nateynateynate
commented
1 year ago @peternied, @pajuric - I question the necessity of doing this on every single PR, but it would be the most effective as something that takes place before merging with whatever branch we use for production. We'll need some back and forth with the authors - that's fine to take place in main. this is meant to be a last line of defense against merging with production without the meta tags properly available.
dtaivpp
commented
1 year ago Yeah this seems like the build check should flag if there are unused fields. Maybe we can use the strict variables flag to check for this.
https://talk.jekyllrb.com/t/checking-if-a-variable-exists-with-strict-variables-set/2207
peternied
commented
1 year ago Yeah this seems like the build check should flag if there are unused fields. Maybe we can use the strict variables flag to check for this.
@dtaivpp I did a test run with this flag enabled, nothing was flagged. [Result]
After getting inspired from https://www.ayyjohn.com/posts/linting-a-jekyll-blog-with-mega-linter I've run the suite of mega linter tests on my fork and have some results for this repository. This might be a useful jumping-off point to determine what kind of functionality the maintainers of this project would like to enforce.
No matter what kinds of checks are performed, I would highly encourage running them on every revision of a PR and requiring them to pass before merging changes. As vigilant as maintainers can be, tools never sleep or go on vacation.
+----SUMMARY----+--------------------------+---------------+-------+-------+--------+--------------+
| Descriptor | Linter | Mode | Files | Fixed | Errors | Elapsed time |
+---------------+--------------------------+---------------+-------+-------+--------+--------------+
| ✅ ACTION | actionlint | list_of_files | 2 | | 0 | 0.01s |
| ◬ BASH | bash-exec | file | 5 | | 1 | 0.02s |
| ❌ BASH | shellcheck | list_of_files | 5 | | 37 | 0.08s |
| ✅ BASH | shfmt | list_of_files | 5 | 5 | 0 | 0.23s |
| ❌ COFFEE | coffeelint | file | 2 | | 1 | 1.61s |
| ❌ COPYPASTE | jscpd | project | n/a | | 87 | 10.27s |
| ❌ CSS | scss-lint | file | 28 | | 27 | 15.37s |
| ❌ CSS | stylelint | list_of_files | 28 | 10 | 1 | 3.17s |
| ✅ DOCKERFILE | hadolint | list_of_files | 1 | | 0 | 0.08s |
| ❌ HTML | djlint | list_of_files | 68 | | 238 | 3.55s |
| ❌ HTML | htmlhint | list_of_files | 68 | | 315 | 0.32s |
| ❌ JAVASCRIPT | standard | list_of_files | 24 | 20 | 1 | 11.55s |
| ✅ JSON | eslint-plugin-jsonc | list_of_files | 13 | 1 | 0 | 1.28s |
| ✅ JSON | jsonlint | list_of_files | 13 | | 0 | 0.21s |
| ❌ JSON | npm-package-json-lint | project | n/a | | 1 | 0.49s |
| ✅ JSON | prettier | list_of_files | 13 | 8 | 0 | 0.83s |
| ✅ JSON | v8r | list_of_files | 13 | | 0 | 15.12s |
| ◬ MARKDOWN | markdownlint | list_of_files | 169 | 61 | 444 | 2.04s |
| ❌ MARKDOWN | markdown-link-check | list_of_files | 169 | | 102 | 207.83s |
| ✅ MARKDOWN | markdown-table-formatter | list_of_files | 169 | 64 | 0 | 0.7s |
| ❌ REPOSITORY | checkov | project | n/a | | 40 | 15.79s |
| ❌ REPOSITORY | devskim | project | n/a | | 9 | 0.74s |
| ✅ REPOSITORY | dustilock | project | n/a | | 0 | 6.25s |
| ✅ REPOSITORY | gitleaks | project | n/a | | 0 | 1.98s |
| ❌ REPOSITORY | git_diff | project | n/a | | 1 | 0.23s |
| ✅ REPOSITORY | secretlint | project | n/a | | 0 | 17.49s |
| ✅ REPOSITORY | syft | project | n/a | | 0 | 1.22s |
| ❌ REPOSITORY | trivy | project | n/a | | 1 | 4.97s |
| ❌ RUBY | rubocop | file | 3 | 3 | 3 | 7.35s |
| ❌ SPELL | cspell | list_of_files | 348 | | 2057 | 143.08s |
| ✅ SPELL | misspell | list_of_files | 347 | 46 | 0 | 0.55s |
| ❌ XML | xmllint | list_of_files | 2 | 0 | 1 | 0.24s |
| ✅ YAML | prettier | list_of_files | 22 | 19 | 0 | 1.36s |
| ❌ YAML | v8r | list_of_files | 22 | | 1 | 18.98s |
| ❌ YAML | yamllint | list_of_files | 22 | | 1 | 0.72s |
+---------------+--------------------------+---------------+-------+-------+--------+--------------+I'm starting to feel inclined to automate this process. I'm going to move this up in priority, as there are more things we're going to need to check the frontmatter on, not just blogs.
kaimmej
commented
1 week ago Check for top level categories and blog metadata. Can use Veil?
Is your feature request related to a problem? Please describe. When authoring a blog post is hard to know what the required metadata values are and if they have been added correctly.
Describe the solution you'd like If there was a check as part of the pull request that scanned the metadata and provided actionable steps on how to resolve these issues it would be much clearer
Describe alternatives you've considered Continue to manually audit blog post metadata content
Additional context Some posts such as this one are not properly showing metadata in the head,
<meta name="keywords" content="open-source, search, opensearch">where as the following are what was included in the document.https://github.com/opensearch-project/project-website/blob/438b67951edbdb0c8836d1bfc1675b750cf9e2fc/_posts/2023-01-11-similar-document-search.md?plain=1#L1-L10