You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2. This will open a window where you can sign in to your Slack workspace.
19
-
20
-
<divdata-full-width="false">
21
-
22
-
<figure><imgsrc="../.gitbook/assets/testtrunkintegration.slack.com_oauth_client_id=1523871431059.3961451315218&scope=incoming-webhook,channels:join,channels:manage&user_scope=&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>
23
-
24
-
</div>
25
-
26
19
3. Once you press **Allow**, Trunk will connect to your Slack automatically and begin pushing updates to the channel you have selected.
Copy file name to clipboardexpand all lines: ci-analytics/readme.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,15 @@ description: See live and trend data about the performance and flakiness of your
6
6
7
7
## Overview
8
8
9
-
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.
9
+
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.
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.
Copy file name to clipboardexpand all lines: cli/compatibility.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Trunk only supports Windows with the following versions and above:
14
14
15
15
<table><thead><tr><thwidth="112.33333333333331">Tool</th><thwidth="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>
16
16
17
-
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.
17
+
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.
Copy file name to clipboardexpand all lines: cli/configuration/README.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
# Configuration
2
2
3
-
The Trunk CLI has its top-level config defined in `.trunk/trunk.yaml`. 
3
+
The Trunk CLI has its top-level config defined in `.trunk/trunk.yaml`.
4
4
5
5
```
6
6
/your_repo
@@ -15,7 +15,7 @@ This is initially generated by `trunk init` and is the central source of truth f
15
15
16
16
### Config Format
17
17
18
-
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).
18
+
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).
Copy file name to clipboardexpand all lines: cli/configuration/actions/notifications.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ description: >-
8
8
9
9
### Defining actions that produce notifications
10
10
11
-
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`.
11
+
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`.
12
12
13
13
In this case, the action should print yaml to output with the following structure:
14
14
@@ -29,10 +29,10 @@ notifications:
29
29
30
30
Some notes:
31
31
32
-
1. The ID can be whatever you want it to, but generally should be made to match the action ID.
32
+
1. The ID can be whatever you want it to be, but generally should be made to match the action ID.
33
33
2. You may emit multiple notifications per action.
34
34
3. `icon` and `commands` are used to control notifications display in VSCode.
35
-
4. Highpriority notifications are immediately shown to the user in terminal. Lowpriority notifications are only shown every 24 hours (These are configurable).
35
+
4. High-priority notifications are immediately shown to the user in terminal. Low-priority notifications are only shown every 24 hours (These are configurable).
Copy file name to clipboardexpand all lines: cli/configuration/lint/definitions.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -24,15 +24,15 @@ The definition of a particular linter is put under `lint.definitions`. The follo
24
24
25
25
## `direct_configs`
26
26
27
-
`direct_configs`: _string list_. Indicates config files used to autoenable the linter. See [Auto Enabling](auto-enable.md).
27
+
`direct_configs`: _string list_. Indicates config files used to auto-enable the linter. See [Auto Enabling](auto-enable.md).
28
28
29
29
## `disabled`
30
30
31
31
`disabled`: _optional boolean_: Whether linter is actively disabled (and will not be recommended) and will not run (overrides enabled).
32
32
33
33
## `download`
34
34
35
-
`download`: _string_. The download url. You must provide either runtime + packages or download, not both. Using runtimes is preferred. See [Runtimes](../runtimes.md).
35
+
`download`: _string_. The download URL. You must provide either runtime + packages or download, not both. Using runtimes is preferred. See [Runtimes](../runtimes.md).
36
36
37
37
## `enabled`
38
38
@@ -44,15 +44,15 @@ The definition of a particular linter is put under `lint.definitions`. The follo
44
44
45
45
## `extra_packages`
46
46
47
-
`extra_packages`: list of strings, Extra packages to install, versions are optional See [Linter Dependencies](dependencies.md).
47
+
`extra_packages`: list of strings, Extra packages to install, versions are optional. See [Linter Dependencies](dependencies.md).
48
48
49
49
## `formatter`
50
50
51
51
`formatter`: _boolean_. Indicates whether this is a formatter and should be included in `trunk fmt`.
52
52
53
53
## `good_without_config`
54
54
55
-
`good_without_config`: _optional boolean_. Indicates whether this linter is recommended without the user tuning its configuration. Prefer [`suggest_if`](definitions.md#suggest\_if).
55
+
`good_without_config`: _optional boolean_. Indicates whether this linter is recommended without the user tuning its configuration. Prefer [`suggest_if`](definitions.md#suggest_if).
Copy file name to clipboardexpand all lines: cli/configuration/lint/output-parsing.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -33,11 +33,11 @@ The execution model that `trunk` follows for a parser is that it will:
33
33
* assert that the exit code of the parser is 0, and then
34
34
* use `output` to determine how it should parse the parser's `stdout`.
35
35
36
-
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).
36
+
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).
37
37
38
38
{% tabs %}
39
39
{% tab title="node" %}
40
-
#### Node
40
+
**Node**
41
41
42
42
```yaml
43
43
lint:
@@ -77,7 +77,7 @@ Remember to run `chmod u+x todo-finder-parser.js` so that `trunk` can run it!
Copy file name to clipboardexpand all lines: cli/configuration/lint/output.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ The output format that Trunk expects from a linter is determined by its [`output
16
16
17
17
## Output Types
18
18
19
-
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.
19
+
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.
20
20
21
21
Trunk currently supports the following linter output types.
Copy file name to clipboardexpand all lines: cli/configuration/plugins/README.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -5,20 +5,20 @@
5
5
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.
6
6
7
7
{% hint style="info" %}
8
-
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.`
8
+
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.`
9
9
{% endhint %}
10
10
11
11
When using trunk, you can merge several sets of configuration files with a `trunk.yaml` schema. Config merging proceeds as follows:
12
12
13
13
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.
14
-
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.
14
+
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.
15
15
3. Optionally, `.trunk/user.yaml`, a local **git-ignored** file where users can provide their own overrides.
16
16
17
17
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`.
18
18
19
19
### Importing a Plugin Repository
20
20
21
-
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.
21
+
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.
Copy file name to clipboardexpand all lines: cli/configuration/plugins/exported-configs.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Reusing linter configs across projects.
4
4
5
5
# Exporting Linter Configs
6
6
7
-
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:
7
+
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:
8
8
9
9
```yaml
10
10
lint:
@@ -17,15 +17,15 @@ lint:
17
17
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`.
18
18
19
19
Plugin-exported configs are sourced in lockstep with the plugin itself, so you will need to update\
20
-
the `ref` field in order to use the latest configs.
20
+
the `ref` field to use the latest configs.
21
21
22
22
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>`.
23
23
24
24
For an example of a plugin repo with config files, see our own [configs](https://github.com/trunk-io/configs) repo.
25
25
26
26
### Importing Configs
27
27
28
-
This process can also be reversed in order to import config files from a plugins repository which\
28
+
This process can also be reversed to import config files from a plugins repository which\
29
29
does not explicitly export them. Given a plugin sourced with id `trunk`, the sourcing repository can\
30
30
achieve the same effect by including the following in its `.trunk/trunk.yaml`.
0 commit comments