Add markdownlint cli for local markdown linting

VSpaceCode / vspacecode.github.io

VSpaceCode website

https://vspacecode.github.io

3 stars 23 forks source link

Add markdownlint cli for local markdown linting #33

Closed stevenguh closed 3 years ago

stevenguh commented 3 years ago

This PR adds local lint command. Repurposing the deploy action to run the npm lint instead a dedicate gh action for lint so local env and gh env share the same linting code and process as well re-using the npm install gh action process

stevenguh commented 3 years ago

However, this might not work for the other two branches

MarcoIeni commented 3 years ago

However, this might not work for the other two branches

Maybe it is enough to put it in the ci.yml file like it was before with the rules specified on top of it.

Anyway it's not working. The current README contains errors that are not detected:

stevenguh commented 3 years ago

Finally, took many tries to get the gh action working the way I wanted to. The current actions will only require one action to run all the necessary steps:

All pushes, pull requests will run the build and lint steps
Only push to master will run the deploy steps in addition to build and lint
Lint is a local runnable command directly with npm script (npm run lint)
Only one npm install for action so ideally save some gh-action hours?

Anyway it's not working. The current README contains errors that are not detected:

Good catch!! This apparently was due to a pair of missing quotes in the command ('**/*.md')

stevenguh commented 3 years ago

This gh action business is tricky. To avoid duplicate action I can't use on: [push, pull_request]. I updated so the ci action so it will only run on push/pr to master, which-key-next, vspacecode-next. This way it should prevent action being run twice if someone push to a branch of a pr to one of those branches (e.g. this pr).

However, duplication can still happen. For example, if there is open pr from which-key-next to master, and someone push to which-key-next.

We might able to avoid duplication completely with https://github.com/fkirc/skip-duplicate-actions/#skip-duplicate-workflow-runs. However, I think the current setup is good enough (and simple) that we shouldn't see duplication that often.

MarcoIeni commented 3 years ago

Great job! Apart for that small comment I left it looks good to me, so you can merge it after you accepted/rejected that suggestion.