c496921d44
Issue #10659 lists a number of extra linting checks that we could enable in order to make our Go code more robust. This commit implements as many as seem sensible: * `durationcheck`, which checks for multiplication of `time.Duration`s, which can lead to unexpected behaviour (e.g. `time.Second * time.Second` is *not* one second) * `goprintffuncname`, which checks that `Printf`-like functions are appropriately suffixed with `f` to indicate as such * `tenv`, which checks for `os.Setenv` in tests where `t.Setenv` is generally a better solution * `wastedassign`, which checks for assignments whose values are never used (such as initial values before an `if` where both branches then overwrite the value) * `whitespace`, which checks for blank lines at the beginning and end of blocks such as functions, `if`s, `for`s and so on. This commit does *not* enable the following checks listed in #10659: * `wrapcheck`, which insists that third-party library errors are always `%w`rapped -- we have a lot of cases where we don't do this and it's probably a bit more involved than "just wrap them" in terms of making sure we don't break anything (maybe) * `predeclared`, which checks for shadowing of existing Go identifiers -- we use `old` and `new` a lot, especially in step generation, so this is probably a slightly bigger clean-up/one we might want to opt out of * `mnd` (magic number detection) -- we have a lot of failures on this * `nilnil` -- we only have a couple of failures on this; these could probably be handled with `//nolint` but for now I've opted not to take this route. |
||
|---|---|---|
| .. | ||
| templates | ||
| testdata | ||
| README.md | ||
| constructor_syntax_extractor.go | ||
| constructor_syntax_generator.go | ||
| constructor_syntax_generator_test.go | ||
| description.go | ||
| description_test.go | ||
| examples.go | ||
| gen.go | ||
| gen_function.go | ||
| gen_kubernetes.go | ||
| gen_method.go | ||
| gen_test.go | ||
| package_tree.go | ||
| package_tree_test.go | ||
| static_schema_loader.go | ||
| utils.go | ||
| utils_test.go | ||
README.md
(docsgen)=
Documentation
This package supports generating documentation for Pulumi packages from their schema.
Crash course on templates
The templates use Go's built-in html/template package to process templates with data. The driver for this doc generator (e.g. tfbridge for TF-based providers) then persists each file from memory onto the disk as .md files.
Although we are using the html/template package, it has the same exact interface as the text/template package, except for some HTML specific things. Therefore, all of the functions available in the text/template package are also available with the html/template package.
- Data can be injected using
{{.PropertyName}}. - Nested properties can be accessed using the dot notation, i.e.
{{.Property1.Property2}}. - Templates can inject other templates using the
{{template "template_name"}}directive.- For this to work, you will need to first define the named template using
{{define "template_name"}}.
- For this to work, you will need to first define the named template using
- You can pass data to nested templates by simply passing an argument after the template's name.
- To remove whitespace from injected values, use the
-in the template tags.- For example,
{{if .SomeBool}} some text {{- else}} some other text {{- end}}. Note the use of-to eliminate whitespace from the enclosing text. - Read more here.
- For example,
- To render un-encoded content use the custom global function
htmlSafe.- Note: This should only be used if you know for sure you are not injecting any user-generated content, as it by-passes the HTML encoding.
- To render strings to Markdown, use the custom global function
markdownify. - To print regular strings, that share the same syntax as the Go templating engine, use the built-in global function
printfunction.
Learn more from here: https://curtisvermeeren.github.io/2017/09/14/Golang-Templates-Cheatsheet
Modifying templates and updating tests
We run tests that validate our template-rendering output. If you need to make change that produces a set of Markdown files that differs from the set that we use in our tests (see codegen/testing/test/testdata/**/*.md), your pull-request checks will fail, and to get them to pass, you'll need to modify the test data to match the output produced by your change.
For minor diffs, you can just update the test files manually and include those updates with your PR. But for large diffs, you may want to regenerate the full set. To do that, from the root of the repo, run:
cd pkg/codegen/docs && PULUMI_ACCEPT=true go test . && cd -