add tags and boost for pages

docs/v1/examples/arguments.md

@@ -1,4 +1,7 @@
-### Arguments
+---
+tags:
+  - v1
+---
 
 You can lookup arguments by calling the `Args` function on `cli.Context`, e.g.:
 

docs/v1/examples/bash-completions.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 You can enable completion commands by setting the `EnableBashCompletion`
 flag on the `App` object.  By default, this setting will only auto-complete to
 show an app's subcommands, but you can write your own completion methods for

docs/v1/examples/combining-short-options.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 Traditional use of options using their shortnames look like this:
 
 ```

docs/v1/examples/exit-codes.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 Calling `App.Run` will not automatically call `os.Exit`, which means that by
 default the exit code will "fall through" to being `0`.  An explicit exit code
 may be set by returning a non-nil error that fulfills `cli.ExitCoder`, *or* a

docs/v1/examples/flags.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 Setting and querying flags is simple.
 
 <!-- {

docs/v1/examples/generated-help-text.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 The default help flag (`-h/--help`) is defined as `cli.HelpFlag` and is checked
 by the cli internals in order to print generated help text for the app, command,
 or subcommand, and break execution.

docs/v1/examples/greet.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 Being a programmer can be a lonely job. Thankfully by the power of automation
 that is not the case! Let's create a greeter app to fend off our demons of
 loneliness!

docs/v1/examples/subcommands-categories.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 For additional organization in apps that have many subcommands, you can
 associate a category for each command to group them together in the help
 output.

docs/v1/examples/subcommands.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 Subcommands can be defined for a more git-like command line app.
 
 <!-- {

docs/v1/examples/version-flag.md

@@ -1,4 +1,7 @@
-### Version Flag
+---
+tags:
+  - v1
+---
 
 The default version flag (`-v/--version`) is defined as `cli.VersionFlag`, which
 is checked by the cli internals in order to print the `App.Version` via

docs/v1/getting-started.md

@@ -1,3 +1,8 @@
+---
+tags:
+  - v1
+---
+
 One of the philosophies behind cli is that an API should be playful and full of
 discovery. So a cli app can be as little as one line of code in `main()`.
 

docs/v1/migrating-to-v2.md

@@ -1,4 +1,7 @@
-## Migrating to V2
+---
+tags:
+  - v1
+---
 
 There are a small set of breaking changes between v1 and v2.
 Converting is relatively straightforward and typically takes less than

docs/v2/examples/arguments.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 You can lookup arguments by calling the `Args` function on `cli.Context`, e.g.:
 
 <!-- {

docs/v2/examples/bash-completions.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 You can enable completion commands by setting the `EnableBashCompletion` flag on
 the `App` object to `true`.  By default, this setting will allow auto-completion
 for an app's subcommands, but you can write your own completion methods for the

docs/v2/examples/combining-short-options.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Traditional use of options using their shortnames look like this:
 
 ```sh-session

docs/v2/examples/exit-codes.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Calling `App.Run` will not automatically call `os.Exit`, which means that by
 default the exit code will "fall through" to being `0`.  An explicit exit code
 may be set by returning a non-nil error that fulfills `cli.ExitCoder`, *or* a

docs/v2/examples/flags.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Setting and querying flags is simple.
 
 <!-- {

docs/v2/examples/full-api-example.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 **Notice**: This is a contrived (functioning) example meant strictly for API
 demonstration purposes. Use of one's imagination is encouraged.
 

docs/v2/examples/generated-help-text.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 The default help flag (`-h/--help`) is defined as `cli.HelpFlag` and is checked
 by the cli internals in order to print generated help text for the app, command,
 or subcommand, and break execution.

docs/v2/examples/greet.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Being a programmer can be a lonely job. Thankfully by the power of automation
 that is not the case! Let's create a greeter app to fend off our demons of
 loneliness!

docs/v2/examples/subcommands-categories.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 For additional organization in apps that have many subcommands, you can
 associate a category for each command to group them together in the help
 output, e.g.:

docs/v2/examples/subcommands.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Subcommands can be defined for a more git-like command line app.
 
 <!-- {

docs/v2/examples/suggestions.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 To enable flag and command suggestions, set `app.Suggest = true`. If the suggest
 feature is enabled, then the help output of the corresponding command will
 provide an appropriate suggestion for the provided flag or subcommand if

docs/v2/examples/timestamp-flag.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 Using the timestamp flag is simple. Please refer to
 [`time.Parse`](https://golang.org/pkg/time/#example_Parse) to get possible
 formats.

docs/v2/examples/version-flag.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 The default version flag (`-v/--version`) is defined as `cli.VersionFlag`, which
 is checked by the cli internals in order to print the `App.Version` via
 `cli.VersionPrinter` and break execution.

docs/v2/getting-started.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 One of the philosophies behind cli is that an API should be playful and full of
 discovery. So a cli app can be as little as one line of code in `main()`.
 

docs/v2/migrating-from-older-releases.md

@@ -1,3 +1,10 @@
+---
+tags:
+  - v2
+search:
+  boost: 2
+---
+
 There are a small set of breaking changes between v1 and v2.  Converting is
 relatively straightforward and typically takes less than an hour. Specific steps
 are included in [Migration Guide: v1 to v2](../migrate-v1-to-v2.md). Also see