mirror of https://github.com/k3s-io/k3s
4636af5b87
The standard Git convention is "origin", not "upstream", so make it flexible in the scripts for those who are set up differently. |
||
|---|---|---|
| .. | ||
| testdata | ||
| README.md | ||
| analytics.go | ||
| analytics_test.go | ||
| example_syncer.go | ||
| example_syncer_test.go | ||
| headers.go | ||
| headers_test.go | ||
| kubectl_dash_f.go | ||
| kubectl_dash_f_test.go | ||
| links.go | ||
| links_test.go | ||
| mungedocs.go | ||
| preformatted.go | ||
| preformatted_test.go | ||
| toc.go | ||
| toc_test.go | ||
| unversioned_warning.go | ||
| unversioned_warning_test.go | ||
| util.go | ||
| util_test.go | ||
| whitespace.go | ||
| whitespace_test.go | ||
README.md
Documentation Mungers
Basically this is like lint/gofmt for md docs.
It basically does the following:
- iterate over all files in the given doc root.
- for each file split it into a slice (mungeLines) of lines (mungeLine)
- a mungeline has metadata about each line typically determined by a 'fast' regex.
- metadata contains things like 'is inside a preformmatted block'
- contains a markdown header
- has a link to another file
- etc..
- if you have a really slow regex with a lot of backtracking you might want to write a fast one to limit how often you run the slow one.
- each munger is then called in turn
- they are given the mungeLines
- they create an entirely new set of mungeLines with their modifications
- the new set is returned
- the new set is then fed into the next munger.
- in the end we might commit the end mungeLines to the file or not (--verify)