* fix(docs): typos which were reflacted from vale linter's command
* feat: Implement Vale linter (#2031)
Initialize .vale.ini file
Add 'lint:docs' script to package.json, to lint all md files except the ones which are located in node_modules
Generate 'vocab.txt' by using command 'yarn run lint:docs' | grep -o ''[a-z A-Z]*'' | grep -o '[a-z A-Z]*' | sort | uniq > .github/styles/vocab.txt
Add steps to github workflow 'master' to check docs quality
* chore: Separate workflow for quality checking
* chore: Added 'shx' dev dependency to support grep command in cross platform
* feat: Add script to operate same quality check process on different platform
* ignore: remove lint:docs from lint-stages which was added for experiment purpose
* fix: check-all-files on push event & check-changed-files on pull_request event
* chore(CI): triggle workflow only when there is any updates in .md file(s) on pull request
* fix: use spawnSync to solve 'The command line is too long.' error
* fix: github workflow syntax
* fix: prettier error
* chore: add vale command directly to lint-staged
* chore: use shebang for easy access
* fix: windows script issue & remove shebang
* chore: Add shebang flag
* chore: better error message related to vale
* chore: mention vale linter in documentation
* fix: spelling errors & add keywords to vocab.txt
Made some small improvements to the FAQ. These include using the correct way to write RST and AsciiDoc, a link to the MKDocs Material Theme repo and some small style/grammar changes to the text about file formats.
* Use a flag to determine wether to use techdocs-container or local install of mkdocs
* Updated techdocs generator to look at app-config string instead of argument to decide how to run the generator
* Removed console log...
* Reverted scaffolder file that was accidentally committed.
* Fixed lint issues
* Added config to create-app template
This adds a GitLab integration for the scaffolder backend.
We're introduceing a preparer and a publisher for GitLab so that we can
read templates from GitLab and publish them to a configured GitLab
instance. The two instances don't need to be the same. For instance,
templates could be public on gitlab.com, but the created repos will live
in a hosted GitLab somewhere else.
The publisher gets its own config object in `app-config.yaml` where the
target instance and token can be specified.
The service catalogue defines both `gitlab` and `gitlab/api` as
processors. They are both handled by the same preparer.
Closes#2372
Oliver Sand