Add tldr tmt pages #3176
Add tldr tmt pages #3176
Conversation
martinhoyer
added
documentation
docs/tldr/pages/linux/tmt.md
Outdated
| - View documentation for tmt-try: | ||
|
|
||
| `tldr tmt-try` |
There was a problem hiding this comment.
How does the [See also: \command1`, `command2`](https://github.com/tldr-pages/tldr/blob/main/CONTRIBUTING.md#subcommands) work from their documentation? I think we could combine the instructions for both tmt runandtmt try` into one snippet?
There was a problem hiding this comment.
Well, I was following their example. +1 for "See also"
docs/tldr/pages/linux/tmt.md
Outdated
| - Show what tests a specific plan would run: | ||
|
|
||
| `tmt run -vv discover plan -n <plan_name>` | ||
|
|
||
| - Show test results from the last run in a web browser: | ||
|
|
||
| `tmt run -l report --how html --open` |
There was a problem hiding this comment.
How about documenting first:
tmt run <discover|provision|prepare|...>: as run only the steptmt run -a <discover|provision|prepare|...>: as run all original steps and override- Example1:
tmt run -v discover: Show all tests that would run
docs/tldr/pages/linux/tmt.md
Outdated
|
|
||
| - Add context to a test run: | ||
|
|
||
| `tmt -c foo=bar -c baz=qux,quux run [...]` |
There was a problem hiding this comment.
I would put <run|...> to indicate that you can use this for other things, e.g. show would give you the expanded format after adjust is applied.
The former is doable. We can use
I don't think it would be easy to do, e.g. |
martinhoyer
requested review from
psss,
lukaszachy,
happz,
thrix and
janhavlin
as code owners
| - View documentation for `tmt run`: | ||
|
|
||
| `tldr tmt-run` | ||
|
|
||
| - View documentation for `tmt try`: | ||
|
|
||
| `tldr tmt-try` |
There was a problem hiding this comment.
| - View documentation for `tmt run`: | |
| `tldr tmt-run` | |
| - View documentation for `tmt try`: | |
| `tldr tmt-try` | |
| - View sub-commands documentations `tmt <run|try>`: | |
| `tldr tmt-<run|try>` |
Should we consolidate these?
There was a problem hiding this comment.
hmm, maybe. In order to replace it with different example? Otherwise it might be more understandable as is.
| - Validate metadata: | ||
|
|
||
| `tmt lint` |
There was a problem hiding this comment.
| - Validate metadata: | |
| `tmt lint` | |
| - Validate `tmt` files: | |
| `tmt lint` |
Could be more specific here I think.
There was a problem hiding this comment.
+1 for being more specific. I'm sure @psss will have the perfect words. :)
| - Use filter: | ||
|
|
||
| `tmt tests ls --filter tag:foo --filter tier:0` |
There was a problem hiding this comment.
I think -c context would be more interesting to document, e.g. "Tmt tests can change due to the context in which it runs"
tmt -c distro=foo tests show
This would be overlapping with the tmt run documented part though 🤔
| - Allow only specific provision plugins: | ||
|
|
||
| `tmt run -a provision --allowed-how 'container|local|virtual'` | ||
|
|
||
| - Disable output capturing and interact directly with the test from the terminal: | ||
|
|
||
| `tmt run --all execute --how tmt --interactive` |
There was a problem hiding this comment.
I think these are a bit too specialized, and can depend on the implementation. How about having a tl;dr part that is more abstract demystifying what the keywords do
| - Allow only specific provision plugins: | |
| `tmt run -a provision --allowed-how 'container|local|virtual'` | |
| - Disable output capturing and interact directly with the test from the terminal: | |
| `tmt run --all execute --how tmt --interactive` | |
| - Overwrite (or add) a step that is otherwise read from the `.fmf` definition | |
| `tmt run -a <discover|provision|prepare|...> (--insert) ...` |
Co-authored-by: Cristian Le <github@lecris.me>
tldr.sh linter accepts only 8 examples and I find it quite hard to pick which ones to cut.
I'm thinking it might be a good idea to create a
tmt runsubcommand page in the same fashion astmt try. What do you think?I also have questions about maintainability.
Resolves #968
Pull Request Checklist