GITBOOK-698: No subject

administration/integration-for-slack.md

@@ -16,13 +16,6 @@ To receive notifications and/or interact with Trunk from Slack, an admin needs t
 
     <figure><img src="https://files.readme.io/14d4355-image.png" alt=""><figcaption></figcaption></figure>
 2. This will open a window where you can sign in to your Slack workspace.
-
-<div data-full-width="false">
-
-<figure><img src="../.gitbook/assets/testtrunkintegration.slack.com_oauth_client_id=1523871431059.3961451315218&#x26;scope=incoming-webhook,channels:join,channels:manage&#x26;user_scope=&#x26;redirect_uri=https:/app.trunk.io/slack/07e100e0-5053-42ed-8d13-cd953bba3b42" alt="Dialog to connect Trunk to your Slack workspace" width="563"><figcaption></figcaption></figure>
-
-</div>
-
 3. Once you press **Allow**, Trunk will connect to your Slack automatically and begin pushing updates to the channel you have selected.
 
 ## Set repo-level notification preferences

ci-analytics/readme.md

@@ -6,15 +6,15 @@ description: See live and trend data about the performance and flakiness of your
 
 ## Overview
 
-Trunk CI Analytics unifies information about CI performance, trends, and reliability. CI Analytics provides powerful dashboards that allow you to understand your CI systems' health quickly. CI Analytics gives developers the tools they need to investigate, triage, and fix performance and reliability problems that slow down your engineering teams.
+Trunk CI Analytics unifies information about CI performance, trends, and reliability. CI Analytics provides powerful dashboards that allow you to understand your CI systems' health quickly. CI Analytics gives developers the tools they need to investigate, triage, and fix performance and reliability problems that slow down engineering teams.
 
 {% embed url="https://share.vidyard.com/watch/wwnfuxL7ETg36DJrF2RBEZ" %}
 
 ## Integrations
 
 Trunk CI Analytics integrates with the following CI providers to gather pipeline metrics that track the performance and results of your CI systems.
 
-<table data-column-title-hidden data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>GitHub Actions</td><td></td><td></td><td><a href="../.gitbook/assets/Group 1274.png">Group 1274.png</a></td><td><a href="setup/github-actions.md">github-actions.md</a></td></tr><tr><td><strong>Jenkins</strong></td><td></td><td></td><td><a href="../.gitbook/assets/Group 1273.png">Group 1273.png</a></td><td><a href="setup/jenkins.md">jenkins.md</a></td></tr><tr><td>Buildkite</td><td></td><td></td><td><a href="../.gitbook/assets/Group 1276.png">Group 1276.png</a></td><td><a href="setup/api.md">api.md</a></td></tr><tr><td>CircleCI</td><td></td><td></td><td><a href="../.gitbook/assets/Group 1275.png">Group 1275.png</a></td><td><a href="setup/api.md">api.md</a></td></tr><tr><td>API</td><td></td><td></td><td><a href="../.gitbook/assets/Group 1277.png">Group 1277.png</a></td><td><a href="setup/api.md">api.md</a></td></tr></tbody></table>
+<table data-column-title-hidden data-view="cards"><thead><tr><th></th><th data-hidden></th><th data-hidden></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td>GitHub Actions</td><td></td><td></td><td><a href="../.gitbook/assets/github.png">github.png</a></td><td><a href="setup/github-actions.md">github-actions.md</a></td></tr><tr><td><strong>Jenkins</strong></td><td></td><td></td><td><a href="../.gitbook/assets/jenkins.png">jenkins.png</a></td><td><a href="setup/jenkins.md">jenkins.md</a></td></tr><tr><td>Buildkite</td><td></td><td></td><td><a href="../.gitbook/assets/bazel.png">bazel.png</a></td><td><a href="setup/api.md">api.md</a></td></tr><tr><td>CircleCI</td><td></td><td></td><td><a href="../.gitbook/assets/circle-ci.png">circle-ci.png</a></td><td><a href="setup/api.md">api.md</a></td></tr><tr><td>API</td><td></td><td></td><td><a href="../.gitbook/assets/Group 1277.png">Group 1277.png</a></td><td><a href="setup/api.md">api.md</a></td></tr></tbody></table>
 
 Don't see your CI Provider listed here? Please contact our community slack at [slack.trunk.io](https://slack.trunk.io) or support at [[email protected]](mailto:[email protected]), and we'll add it.
 

cli/commands-reference/actions.md

@@ -190,7 +190,7 @@ trunk show-announcements post-merge --verbose
 trunk show-announcements pre-rebase [options] [branch-refs...]
 ```
 
-### **Trunk show announcements post checkout**
+### **Trunk show announcements post-checkout**
 
 **`trunk show-announcements post-checkout`**: Run on git checkout/switch, usually run by a git-hook and not directly.
 

cli/commands-reference/code-quality.md

@@ -2,7 +2,7 @@
 
 ### trunk check
 
-`trunk check`: Universal code checker. 
+`trunk check`: Universal code checker.
 
 #### **Usage** **example**
 
@@ -14,7 +14,7 @@ trunk check [options]
 
 * `-a, --all`: Check all files instead of only changed files
 * `--sample`: Run each linter on N files
-* `--filter`: Comma separated list of linters and/or issue codes to include or exclude
+* `--filter`: Comma-separated list of linters and/or issue codes to include or exclude
 * `--exclude`: Shorthand for an inverse --filter
 * `--scope`: Scope of checks to run {all | security}
 * `--ignore`: Glob pattern to exclude files from linting
@@ -50,11 +50,11 @@ trunk check [options]
 * `-n, --no-fix`: Don't automatically apply fixes
 * `--cache`: Disable to skip cache for all check actions
 * `--ignore-git-state`: Run linters even if a merge, rebase, or revert is in progress
-* `--upstream`: Upstream branch used to compute changed files 
+* `--upstream`: Upstream branch used to compute changed files
 
 ### Trunk Check Enable Linter
 
-`trunk check enable`: Enable linters for trunk check. 
+`trunk check enable`: Enable linters for trunk check.
 
 #### **Usage** **example**
 
@@ -64,7 +64,7 @@ trunk check enable [options]
 
 ### Trunk Check Disable Linter
 
-`trunk check disable`: Disable linters for trunk check. 
+`trunk check disable`: Disable linters for trunk check.
 
 #### **Usage** **example**
 
@@ -74,7 +74,7 @@ trunk check disable [options]
 
 ### Trunk Check List Linters
 
-`trunk check list`: List linters for trunk check. 
+`trunk check list`: List linters for trunk check.
 
 #### **Usage** **example**
 
@@ -84,7 +84,7 @@ trunk check list [options]
 
 ### Trunk Check Run Format
 
-`trunk fmt`: List linters for trunk check. 
+`trunk fmt`: List linters for trunk check.
 
 #### **Usage** **example**
 
@@ -97,7 +97,7 @@ trunk fmt [options]
 #### Filtering Options
 
 * `-a, --all`: Check all files instead of only changed files
-* `--filter`: Comma separated list of linters and/or issue codes to include or exclude
+* `--filter`: Comma-separated list of linters and/or issue codes to include or exclude
 * `--exclude`: Shorthand for an inverse --filter
 * `--scope`: Scope of checks to run {all | security}
 * `--ignore`: Glob pattern to exclude files from linting
@@ -126,7 +126,7 @@ trunk fmt [options]
 * `-n, --no-fix`: Don't automatically apply fixes
 * `--cache`: Disable to skip cache for all check actions
 * `--ignore-git-state`: Run linters even if a merge, rebase, or revert is in progress
-* `--upstream`: Upstream branch used to compute changed files 
+* `--upstream`: Upstream branch used to compute changed files
 * `-j`, `--jobs`: Number of concurrent jobs
 
 ## Advanced Trunk Check Features

cli/compatibility.md

@@ -14,7 +14,7 @@ Trunk only supports Windows with the following versions and above:
 
 <table><thead><tr><th width="112.33333333333331">Tool</th><th width="397">Where to Modify</th><th>Minimum Required Version</th></tr></thead><tbody><tr><td>CLI</td><td><code>cli</code> <code>version</code> in <code>.trunk/trunk.yaml</code></td><td><code>1.13.0</code></td></tr><tr><td>Plugins</td><td><code>ref</code> for the <code>trunk</code> plugin in <code>.trunk/trunk.yaml</code></td><td><code>v1.0.0</code></td></tr><tr><td>VSCode</td><td>Reload VSCode to update</td><td><code>3.4.4</code></td></tr></tbody></table>
 
-You will also need to install [C and C++ runtime libraries](https://aka.ms/vs/17/release/vc\_redist.x64.exe) in order to run some linters.
+You will also need to install [C and C++ runtime libraries](https://aka.ms/vs/17/release/vc_redist.x64.exe) to run some linters.
 
 #### Getting in touch
 

cli/configuration/README.md

@@ -1,6 +1,6 @@
 # Configuration
 
-The Trunk CLI has its top-level config defined in `.trunk/trunk.yaml`. 
+The Trunk CLI has its top-level config defined in `.trunk/trunk.yaml`.
 
 ```
 /your_repo
@@ -15,7 +15,7 @@ This is initially generated by `trunk init` and is the central source of truth f
 
 ### Config Format
 
-The Trunk configuration file is written in YAML and is meant to be self-descriptive.Below is a sample config file to help you understand how the pieces come together. Alternatively, you can also refer to [the `trunk.yaml` in our GitHub Action](https://github.com/trunk-io/trunk-action/blob/main/.trunk/trunk.yaml) as an example or [`trunk-yaml-schema.json`](https://static.trunk.io/pub/trunk-yaml-schema.json).
+The Trunk configuration file is written in YAML and is meant to be self-descriptive. Below is a sample config file to help you understand how the pieces come together. Alternatively, you can also refer to [the `trunk.yaml` in our GitHub Action](https://github.com/trunk-io/trunk-action/blob/main/.trunk/trunk.yaml) as an example or [`trunk-yaml-schema.json`](https://static.trunk.io/pub/trunk-yaml-schema.json).
 
 ```yaml
 version: 0.1 # the version of this config file.

cli/configuration/actions/logging-and-troubleshooting.md

@@ -12,13 +12,13 @@ Every action execution is logged. We consider an action execution to have failed
 
 Failed action executions will also produce a notification so that background failures are periodically surfaced to the user.
 
-You can inspect also inspect action logs at `.trunk/out/actions/<action_id>/`.
+You can also inspect action logs at `.trunk/out/actions/<action_id>/`.
 
-We recommend running actions manually when you develop them in order to verify that they work correctly.
+We recommend running actions manually when you develop them to verify that they work correctly.
 
 ### Output Level
 
-In order to see a more verbose output when running trunk actions, particularly from git-hooks, you can add the following to your `trunk.yaml`:
+To see a more verbose output when running trunk actions, particularly from git-hooks, you can add the following to your `trunk.yaml`:
 
 ```yaml
 actions:

cli/configuration/actions/notifications.md

@@ -8,7 +8,7 @@ description: >-
 
 ### Defining actions that produce notifications
 
-Typically, whatever actions write to stdout is stored in the log file and perhaps shown to the user. However, actions can also produce structured output if `output_type` is set on the Action Definition to be `notification_v1`.
+Typically, whatever actions write to stdout are stored in the log file and perhaps shown to the user. However, actions can also produce structured output if `output_type` is set on the Action Definition to be `notification_v1`.
 
 In this case, the action should print yaml to output with the following structure:
 
@@ -29,10 +29,10 @@ notifications:
 
 Some notes:
 
-1. The ID can be whatever you want it to, but generally should be made to match the action ID.
+1. The ID can be whatever you want it to be, but generally should be made to match the action ID.
 2. You may emit multiple notifications per action.
 3. `icon` and `commands` are used to control notifications display in VSCode.
-4. High priority notifications are immediately shown to the user in terminal. Low priority notifications are only shown every 24 hours (These are configurable).
+4. High-priority notifications are immediately shown to the user in terminal. Low-priority notifications are only shown every 24 hours (These are configurable).
 
 ### Deleting notifications
 

cli/configuration/lint/definitions.md

@@ -24,15 +24,15 @@ The definition of a particular linter is put under `lint.definitions`. The follo
 
 ## `direct_configs`
 
-`direct_configs`: _string list_. Indicates config files used to auto enable the linter. See [Auto Enabling](auto-enable.md).
+`direct_configs`: _string list_. Indicates config files used to auto-enable the linter. See [Auto Enabling](auto-enable.md).
 
 ## `disabled`
 
 `disabled`: _optional boolean_: Whether linter is actively disabled (and will not be recommended) and will not run (overrides enabled).
 
 ## `download`
 
-`download`: _string_. The download url. You must provide either runtime + packages or download, not both. Using runtimes is preferred. See [Runtimes](../runtimes.md).
+`download`: _string_. The download URL. You must provide either runtime + packages or download, not both. Using runtimes is preferred. See [Runtimes](../runtimes.md).
 
 ## `enabled`
 
@@ -44,15 +44,15 @@ The definition of a particular linter is put under `lint.definitions`. The follo
 
 ## `extra_packages`
 
-`extra_packages`: list of strings, Extra packages to install, versions are optional See [Linter Dependencies](dependencies.md).
+`extra_packages`: list of strings, Extra packages to install, versions are optional. See [Linter Dependencies](dependencies.md).
 
 ## `formatter`
 
 `formatter`: _boolean_. Indicates whether this is a formatter and should be included in `trunk fmt`.
 
 ## `good_without_config`
 
-`good_without_config`: _optional boolean_. Indicates whether this linter is recommended without the user tuning its configuration. Prefer [`suggest_if`](definitions.md#suggest\_if).
+`good_without_config`: _optional boolean_. Indicates whether this linter is recommended without the user tuning its configuration. Prefer [`suggest_if`](definitions.md#suggest_if).
 
 ## `hold_the_line`
 

cli/configuration/lint/output-parsing.md

@@ -33,11 +33,11 @@ The execution model that `trunk` follows for a parser is that it will:
   * assert that the exit code of the parser is 0, and then
 * use `output` to determine how it should parse the parser's `stdout`.
 
-Note that you can also set `parser.runtime` to [`node`](output-parsing.md#node) or [`python`](output-parsing.md#python) so that you can write your parser in Javascript or Python instead, if you so prefer! You can find plenty examples of python parsers in our [plugins repo](https://github.com/trunk-io/plugins).
+Note that you can also set `parser.runtime` to [`node`](output-parsing.md#node) or [`python`](output-parsing.md#python) so that you can write your parser in Javascript or Python instead, if you so prefer! You can find plenty of examples of python parsers in our [plugins repo](https://github.com/trunk-io/plugins).
 
 {% tabs %}
 {% tab title="node" %}
-#### Node
+**Node**
 
 ```yaml
 lint:
@@ -77,7 +77,7 @@ Remember to run `chmod u+x todo-finder-parser.js` so that `trunk` can run it!
 {% endtab %}
 
 {% tab title="python" %}
-#### Python
+**Python**
 
 ```yaml
 lint:

cli/configuration/lint/output.md

@@ -16,7 +16,7 @@ The output format that Trunk expects from a linter is determined by its [`output
 
 ## Output Types
 
-Trunk supports several different generic output types. Most linters will use one of these output types, but if your linter doesn't conform well to any of these specifications, you can also write a [custom parser](output-parsing.md). In general SARIF should be preferred over other formats because it is the most flexible and battle tested.
+Trunk supports several different generic output types. Most linters will use one of these output types, but if your linter doesn't conform well to any of these specifications, you can also write a [custom parser](output-parsing.md). In general, SARIF should be preferred over other formats because it is the most flexible and battle tested.
 
 Trunk currently supports the following linter output types.
 

cli/configuration/plugins/README.md

@@ -5,20 +5,20 @@
 Trunk uses a plugin system where a root configuration is defined in the [trunk-io/plugin repository](https://github.com/trunk-io/plugins). You can import many plugin config sources, and fields defined at each level override the level above.
 
 {% hint style="info" %}
-When plugins configs are merged, only fields defined in a config file are merged into the level above. You can define just the fields you wish to override in `.trunk/trunk.yaml and .trunk/user.yaml.`
+When plugin configs are merged, only fields defined in a config file are merged into the level above. You can define just the fields you wish to override in `.trunk/trunk.yaml and .trunk/user.yaml.`
 {% endhint %}
 
 When using trunk, you can merge several sets of configuration files with a `trunk.yaml` schema. Config merging proceeds as follows:
 
 1. Remote plugins sourced in `.trunk/trunk.yaml` (and `.trunk/user.yaml`). Plugins are sourced in the order they're defined, with later plugins overriding those defined before it. The [`trunk`](https://github.com/trunk-io/plugins) plugin is implicitly sourced first.
-2. Your repo level `.trunk/trunk.yaml` file, complete with a CLI version and any definitions or enables. Configurations defined here overrides what's defined in the remote plugins.
+2. Your repo level `.trunk/trunk.yaml` file, complete with a CLI version and any definitions or enables. Configurations defined here override what's defined in the remote plugins.
 3. Optionally, `.trunk/user.yaml`, a local **git-ignored** file where users can provide their own overrides.
 
 Additionally, any files enumerated in the lint `exported_configs` section are symlinked from their relevant plugin into the root of the workspace when an applicable linter is run with `trunk check`.
 
 ### Importing a Plugin Repository
 
-By default trunk imports the trunk-io/plugins repository. To import a repo add it to the `plugins.sources` list. Each repo requires a URI and ref.
+By default, trunk imports the trunk-io/plugins repository. To import a repo add it to the `plugins.sources` list. Each repo requires a URI and ref.
 
 ```yaml
 plugins:

cli/configuration/plugins/exported-configs.md

@@ -4,7 +4,7 @@ description: Reusing linter configs across projects.
 
 # Exporting Linter Configs
 
-Plugin repositories can also export their own linter config files in order to keep configuration synced across an organization. Simply add an `exported_configs` section to a `plugin.yaml`, with paths to all of the config files you want to export, relative to the repository root. For example:
+Plugin repositories can also export their own linter config files to keep configuration synced across an organization. Simply add an `exported_configs` section to a `plugin.yaml`, with paths to all of the config files you want to export, relative to the repository root. For example:
 
 ```yaml
 lint:
@@ -17,15 +17,15 @@ lint:
 These config files will be available for linters that enumerate them in `affects_cache`or `direct_configs` to reference. These files are automatically symlinked into the repository root during linter execution. The set of applicable config files can be viewed in the details yaml file listed when running `trunk check --verbose`.
 
 Plugin-exported configs are sourced in lockstep with the plugin itself, so you will need to update\
-the `ref` field in order to use the latest configs.
+the `ref` field to use the latest configs.
 
 Note that if you're using an IDE Extension like clangd with an LSP that relies on those configs being in the root, you will need to manually create a symlink to the plugin's config. You can do this by running `ln -s .trunk/plugins/<plugin-id>/<path-to-config> <name-of-config>`.
 
 For an example of a plugin repo with config files, see our own [configs](https://github.com/trunk-io/configs) repo.
 
 ### Importing Configs
 
-This process can also be reversed in order to import config files from a plugins repository which\
+This process can also be reversed to import config files from a plugins repository which\
 does not explicitly export them. Given a plugin sourced with id `trunk`, the sourcing repository can\
 achieve the same effect by including the following in its `.trunk/trunk.yaml`.