prometheus.json

format: uri-reference

description: Sets the `Authorization` header on every remote write request with the configured username and password. password and password_file are mutually exclusive.

$ref: #/definitions/filepath

description: Sets the `Authorization` header on every scrape request with the configured credentials.

description: Sets the authentication type of the request.

default: Bearer

description: Sets the credentials of the request. It is mutually exclusive with `credentials_file`.

description: Sets the credentials of the request with the credentials read from the configured file. It is mutually exclusive with `credentials`.

description: Optionally configures AWS's Signature Verification 4 signing process to sign requests.

description: The AWS region. If blank, the region from the default credentials chain is used.

description: The AWS API keys. If blank, the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are used.

description: Named AWS profile used to authenticate.

description: AWS Role ARN, an alternative to using AWS API keys.

description: Optional OAuth 2.0 configuration. Cannot be used at the same time as basic_auth or authorization.

description: Read the client secret from a file. It is mutually exclusive with `client_secret`.

description: Scopes for the token request.

description: The URL to fetch the token from.

description: Optional parameters to append to the token URL.

description: Configures the token request's TLS settings.

description: Sets the `Authorization` header on every scrape request with the configured bearer token. It is mutually exclusive with `bearer_token_file`.

description: Sets the `Authorization` header on every scrape request with the bearer token read from the configured file. It is mutually exclusive with `bearer_token`.

description: The source labels select values from existing labels. Their content is concatenated using the configured separator and matched against the configured regular expression for the replace, keep, and drop actions.

description: Separator placed between concatenated source label values.

description: Label to which the resulting value is written in a replace action. It is mandatory for replace actions. Regex capture groups are available.

$comment: https://github.com/prometheus/prometheus/blob/release-2.13/config/testdata/conf.good.yml#L146 has a regex capture group, violating vanilla label_name definition.

description: Regular expression against which the extracted value is matched.

$comment: https://github.com/prometheus/prometheus/blob/release-2.13/config/testdata/conf.good.yml#L111 has integer instead of string

description: Modulus to take of the hash of the source label values.

description: Replacement value against which a regex replace is performed if the regular expression matches. Regex capture groups are available.

description: Action to perform based on regex matching.

enum: replace lowercase uppercase keep drop keepequal dropequal hashmod labelmap labeldrop labelkeep

default: replace

const: replace

description: CA certificate to validate API server certificate with.

description: Certificate file for client cert authentication to the server.

description: Key file for client cert authentication to the server.

description: ServerName extension to indicate the name of the server.

description: Disable validation of the server certificate.

description: List of Azure service discovery configurations.

description: The information to access the Azure API.

description: List of Consul service discovery configurations.

description: The information to access the Consul API. It is to be defined as the Consul documentation requires.

description: List of DigitalOcean service discovery configurations.

description: The information to access the DigitalOcean API.

description: List of Docker service discovery configurations.

description: Docker SD configurations allow retrieving scrape targets from Docker Engine hosts.

description: List of Docker Swarm service discovery configurations.

description: Docker Swarm SD configurations allow retrieving scrape targets from Docker Swarm engine.

description: List of DNS service discovery configurations.

description: A DNS-based service discovery configuration allows specifying a set of DNS domain names which are periodically queried to discover a list of targets. The DNS servers to be contacted are read from /etc/resolv.conf. This service discovery method only supports basic DNS A, AAAA and SRV record queries, but not the advanced DNS-SD approach specified in RFC6763. During the relabeling phase, the meta label __meta_dns_name is available on each target and is set to the record name that produced the discovered target.

description: A list of DNS domain names to be queried.

description: The type of DNS query to perform. One of SRV, A, or AAAA.

enum: SRV A AAAA

default: SRV

description: The port number used if the query type is not SRV.

description: The time after which the provided names are refreshed.

$ref: #/definitions/duration

description: List of EC2 service discovery configurations.

description: The information to access the EC2 API.

description: List of Eureka service discovery configurations.

description: The information to access the Eureka API.

description: List of file service discovery configurations.

description: Patterns for files from which target groups are extracted. Where the pattern may be a path ending in .json, .yml or .yaml. The last path segment may contain a single * that matches any character sequence, e.g. my/path/tg_*.json.

description: Refresh interval to re-read the files.

description: List of GCE service discovery configurations.

description: The information to access the GCE API.

description: List of Hetzner service discovery configurations.

description: The information to access the Hetzner API.

description: List of HTTP service discovery configurations.

description: HTTP-based service discovery provides a more generic way to configure static targets and serves as an interface to plug in custom service discovery mechanisms.

description: URL from which the targets are fetched.

description: Refresh interval to re-query the endpoint.

$ref: #/definitions/authorization

description: Optional proxy URL.

description: Configure whether HTTP requests follow HTTP 3xx redirects.

description: TLS configuration.

$ref: #/definitions/auth

description: List of Kubernetes service discovery configurations.

description: The information to access the Kubernetes API.

description: The API server addresses. If left empty, Prometheus is assumed to run inside of the cluster and will discover API servers automatically and use the pod's CA certificate and bearer token file at /var/run/secrets/kubernetes.io/serviceaccount/.

description: The Kubernetes role of entities that should be discovered. One of endpoints, service, pod, node, or ingress.

enum: endpoints service pod node ingress

description: Optional proxy URL.

description: Configure whether scrape requests follow HTTP 3xx redirects.

description: TLS configuration.

description: Optional namespace discovery. If omitted, all namespaces are used.

description: Optional label and field selectors to limit the discovery process to a subset of available resources.

description: List of Kuma service discovery configurations.

description: The information to access the Kuma API.

description: List of Lightsail service discovery configurations.

description: The information to access the Lightsail API.

description: List of Linode service discovery configurations.

description: The information to access the Linode API.

description: List of Marathon service discovery configurations.

description: List of AirBnB's Nerve service discovery configurations.

description: List of OpenStack service discovery configurations.

description: The information to access the OpenStack API.

description: List of PuppetDB service discovery configurations.

description: The information to access the PuppetDB API.

description: List of Scaleway service discovery configurations.

description: The information to access the Scaleway API.

description: List of Zookeeper Serverset service discovery configurations.

description: List of Triton service discovery configurations.

description: The information to access the Triton discovery API.

description: List of Uyuni service discovery configurations.

description: The information to access the Uyuni API.

description: List of labeled statically configured targets for this job.

description: The targets specified by the static config.

description: Labels assigned to all metrics scraped from the targets.

$ref: #/definitions/labels

description: Prometheus configuration file

description: The global configuration specifies parameters that are valid in all other configuration contexts. They also serve as defaults for other configuration sections.

description: How frequently to scrape targets by default.

description: How long until a scrape request times out.

description: How frequently to evaluate rules.

description: The labels to add to any time series or alerts when communicating with external systems (federation, remote storage, Alertmanager).

description: File to which PromQL queries are logged. Reloading the configuration will reopen the file.

description: Rule files specifies a list of globs. Rules and alerts are read from all matching files.

description: Settings related to the remote write feature.

description: The URL of the endpoint to send samples to.

description: Timeout for requests to the remote write endpoint.

description: Custom HTTP headers to be sent along with each remote write request. Be aware that headers that are set by Prometheus itself can't be overwritten.

description: List of remote write relabel configurations.

description: Name of the remote write config, which if specified must be unique among remote write configs. The name will be used in metrics and logging in place of a generated value to help users distinguish between remote write configs.

description: Enables sending of exemplars over remote write. Note that exemplar storage itself must be enabled for exemplars to be scraped in the first place.

description: Configures the remote write request's TLS settings.

description: Optional proxy URL.

description: Configures the queue used to write to remote storage.

description: Number of samples to buffer per shard before we block reading of more samples from the WAL. It is recommended to have enough capacity in each shard to buffer several requests to keep throughput up while processing occasional slow remote requests.

description: Maximum number of shards, i.e. amount of concurrency.

description: Minimum number of shards, i.e. amount of concurrency.

description: Maximum number of samples per send.

description: Maximum time a sample will wait in buffer.

description: Initial retry delay. Gets doubled for every retry.

description: Maximum retry delay.

description: Retry upon receiving a 429 status code from the remote-write storage.

description: Configures the sending of series metadata to remote storage.

description: Whether metric metadata is sent to remote storage or not.

description: How frequently metric metadata is sent to remote storage.

description: Maximum number of samples per send.

description: Settings related to the remote read feature.

description: The URL of the endpoint to query from.

description: Name of the remote read config, which if specified must be unique among remote read configs. The name will be used in metrics and logging in place of a generated value to help users distinguish between remote read configs.

description: An optional list of equality matchers which have to be present in a selector to query the remote read endpoint.

description: Timeout for requests to the remote read endpoint.

description: Custom HTTP headers to be sent along with each remote read request. Be aware that headers that are set by Prometheus itself can't be overwritten.

description: Whether reads should be made for queries for time ranges that the local storage should have complete data for.

description: Optional proxy URL.

description: Scrape config files specifies a list of globs. Scrape configs are read from all matching files and appended to the list of scrape configs.

description: A list of scrape configurations.

description: The job name assigned to scraped metrics by default. Must be unique across all scrape configurations.

description: How frequently to scrape targets from this job. Defaults to `global.scrape_interval`.

description: Per-scrape timeout when scraping this job. Defaults to `global.scrape_timeout`.

description: The HTTP resource path on which to fetch metrics from targets.

description: Controls how Prometheus handles conflicts between labels that are already present in scraped data and labels that Prometheus would attach server-side ("job" and "instance" labels, manually configured target labels, and labels generated by service discovery implementations).

description: Controls whether Prometheus respects the timestamps present in scraped data.

description: Configures the protocol scheme used for requests.

description: Optional HTTP URL parameters.

description: Configures the scrape request's TLS settings.

description: Optional proxy URL.

description: List of target relabel configurations.

description: List of metric relabel configurations.

description: An uncompressed response body larger than this many bytes will cause the scrape to fail. 0 means no limit. Example: 100MB.

description: Per-scrape limit on number of scraped samples that will be accepted. If more than this number of samples are present after metric relabelling the entire scrape will be treated as failed. 0 means no limit.

description: Per-scrape limit on number of labels that will be accepted for a sample. If more than this number of labels are present post metric-relabeling, the entire scrape will be treated as failed. 0 means no limit.

description: Per-scrape limit on length of labels name that will be accepted for a sample. If a label name is longer than this number post metric-relabeling, the entire scrape will be treated as failed. 0 means no limit.

description: Per-scrape limit on length of labels value that will be accepted for a sample. If a label value is longer than this number post metric-relabeling, the entire scrape will be treated as failed. 0 means no limit.

description: Per-scrape config limit on number of unique targets that will be accepted. If more than this number of targets are present after target relabeling, Prometheus will mark the targets as failed without scraping them. 0 means no limit.

description: Alerting specifies settings related to the Alertmanager.

description: Per-target Alertmanager timeout when pushing alerts.

description: The api version of Alertmanager.

description: Prefix for the HTTP path alerts are pushed to.

description: Optional proxy URL.

description: List of labeled statically configured Alertmanagers.

description: List of Alertmanager relabel configurations.

description: Storage related settings that are runtime reloadable.

title: Prometheus


foxx-manifest.json

description: Schema for ArangoDB Foxx service manifests

type: object

description: An object defining the configuration options this service requires.

type: string

description: A human-readable description of the option.

description: The type of value expected for this option.

enum: integer boolean number string json password int bool

default: string

description: The default value for this option in plain JSON. Can be omitted to provide no default value.

type: boolean

description: Whether the service can not function without this option. Defaults to true unless a default value is provided.

description: If specified, the / (root) route of the service will automatically redirect to the given relative path, e.g. "index.html".

description: The dependencies this service uses, i.e. which APIs its dependencies need to be compatible with.

description: The semantic version ranges of the API the service expects.

description: Name of the API the service expects.

description: A description of how the API is used or why it is needed.

description: Whether the service can not function without this dependency.

description: Whether the dependency can be specified more than once.

description: The dependencies this provides, i.e. which APIs it claims to be compatible with.

description: The semantic version ranges of the API the service implements.

description: An object indicating the semantic version ranges of ArangoDB (or compatible environments) the service will be compatible with.

description: An object defining file assets served by this service.

description: Relative path of the file or folder within the service.

description: If set to true the file will be served with gzip-encoding if supported by the client. This can be useful when serving text files like client-side JavaScript, CSS or HTML.

description: The MIME content type of the file. Defaults to an intelligent guess based on the filename's extension.

description: The relative path to the Foxx JavaScript files in the service, e.g. "lib". Defaults to the folder containing this manifest.

description: The relative path to the main entry point of this service (relative to lib), e.g. "index.js".

description: An object defining named scripts provided by this service, which can either be used directly or as queued jobs by other services.

description: Path of the script (relative to lib), e.g. "scripts/setup.js".

description: A path/pattern or list of paths/patterns of JavaScript tests provided for this service.

type: array

description: A single path/pattern of JavaScript tests provided for this service.

description: The full name of the author of the service (i.e. you). This will be shown in the web interface.

description: A list of names of people that have contributed to the development of the service in some way. This will be shown in the web interface.

description: Human-readable representation of the contributor, e.g. their name.

description: A human-readable description of the service. This will be shown in the web interface.

description: A list of keywords that help categorize this service. This is used by the Foxx Store installers to organize services.

description: A keyword relevant to the service.

description: A string identifying the license under which the service is published, ideally in the form of an SPDX license identifier. This will be shown in the web interface.

description: The name of the Foxx service. This will be shown in the web interface.

description: The filename of a thumbnail that will be used alongside the service in the web interface. This should be a JPEG or PNG image that looks good at sizes 50x50 and 160x160.

description: The version number of the Foxx service. The version number must follow the semantic versioning format. This will be shown in the web interface.


cargo.json

title: Build

description:
The `build` field specifies a file in the package root which is a [build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) for building native code. More information can be found in the [build script guide](https://doc.rust-lang.org/cargo/reference/build-scripts.html).

```toml
[package]
# ...
build = "build.rs"
```

The default is `"build.rs"`, which loads the script from a file named
`build.rs` in the root of the package. Use `build = "custom_build_name.rs"` to
specify a path to a different file or `build = false` to disable automatic
detection of the build script.

description: Path to the build file.

enumValues: Automatically detect the build file (`build.rs`).

enumValues: Disable automatic detection of the build file.

title: Debug Level

description:
The `debug` setting controls the [`-C debuginfo` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo) which controls the
amount of debug information included in the compiled binary.

enumValues: No debug info at all, default for `release` profile

enumValues: Debug info without type or variable-level information. Generates more detailed module-level info than `line-tables-only`.

enumValues: Full debug info, default for `dev` profile

enumValues: Line info directives only. For the nvptx* targets this enables [profiling](https://reviews.llvm.org/D46061). For other use cases, `line-tables-only` is the better, more compatible choice.

enumValues: Line tables only. Generates the minimal amount of debug info for backtraces with filename/line number info, but not anything else, i.e. no variable or function parameter info.

title: Dependency

$ref: #/definitions/SemVerRequirement

$ref: #/definitions/DetailedDependency

title: Detailed Dependency

description: Specify the Git branch to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

description: Use the default features of the dependency.

description: List of features to activate in the dependency.

schemas: feature

description:
To depend on a library located in a `git` repository, the minimum information
you need to specify is the location of the repository with the `git` key:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand" }
```

Cargo will fetch the `git` repository at this location then look for a
`Cargo.toml` for the requested crate anywhere inside the `git` repository
(not necessarily at the root - for example, specifying a member crate name
of a workspace and setting `git` to the repository containing the workspace).

Since we haven't specified any other information, Cargo assumes that
we intend to use the latest commit on the main branch to build our package.
You can combine the `git` key with the `rev`, `tag`, or `branch` keys to
specify something else. Here's an example of specifying that you want to use
the latest commit on a branch named `next`:

```toml
[dependencies]
rand = { git = "https://github.com/rust-lang-nursery/rand", branch = "next" }
```

See [Git Authentication](https://doc.rust-lang.org/cargo/appendix/git-authentication.html) for help with git authentication for private repos.

> **Note**: [crates.io](https://crates.io/) does not allow packages to be published with `git`
> dependencies (`git` [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) are ignored). See the [Multiple
> locations](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-locations) section for a fallback alternative.

description:
Mark the dependency as optional.

Optional dependencies can be activated through features.

description:
Specify the name of the package.

When writing a `[dependencies]` section in `Cargo.toml` the key you write for a
dependency typically matches up to the name of the crate you import from in the
code. For some projects, though, you may wish to reference the crate with a
different name in the code regardless of how it's published on crates.io. For
example you may wish to:

* Avoid the need to  `use foo as bar` in Rust source.
* Depend on multiple versions of a crate.
* Depend on crates with the same name from different registries.

To support this Cargo supports a `package` key in the `[dependencies]` section
of which package should be depended on:

```toml
[package]
name = "mypackage"
version = "0.0.1"

[dependencies]
foo = "0.1"
bar = { git = "https://github.com/example/project", package = "foo" }
baz = { version = "0.1", registry = "custom", package = "foo" }
```

In this example, three crates are now available in your Rust code:

```rust
extern crate foo; // crates.io
extern crate bar; // git repository
extern crate baz; // registry `custom`
```

All three of these crates have the package name of `foo` in their own
`Cargo.toml`, so we're explicitly using the `package` key to inform Cargo that
we want the `foo` package even though we're calling it something else locally.
The `package` key, if not specified, defaults to the name of the dependency
being requested.

description:
Cargo supports **path dependencies** which are typically sub-crates that live within one repository.
Let's start off by making a new crate inside of our `hello_world` package:

```console
# inside of hello_world/
$ cargo new hello_utils
```

This will create a new folder `hello_utils` inside of which a `Cargo.toml` and
`src` folder are ready to be configured. In order to tell Cargo about this, open
up `hello_world/Cargo.toml` and add `hello_utils` to your dependencies:

```toml
[dependencies]
hello_utils = { path = "hello_utils" }
```

This tells Cargo that we depend on a crate called `hello_utils` which is found
in the `hello_utils` folder (relative to the `Cargo.toml` it's written in).

description:
To specify a dependency from a registry other than [crates.io](https://crates.io), first the
registry must be configured in a `.cargo/config.toml` file. See the [registries
documentation](https://doc.rust-lang.org/cargo/reference/registries.html) for more information. In the dependency, set the `registry` key
to the name of the registry to use.

```toml
[dependencies]
some-crate = { version = "1.0", registry = "my-registry" }
```

> **Note**: [crates.io](https://crates.io) does not allow packages to be published with
> dependencies on other registries.

description: Specify the Git revision to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

description: Specify the Git tag to use in case of a [Git dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

title: Edition

description:
The `edition` key affects which edition your package is compiled with. Cargo
will always generate packages via [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) with the `edition` key set to the
latest edition. Setting the `edition` key in `[package]` will affect all
targets/crates in the package, including test suites, benchmarks, binaries,
examples, etc.

title: Lto

description:
The `lto` setting controls the [`-C lto` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#lto) which controls LLVM's [link time optimizations](https://llvm.org/docs/LinkTimeOptimization.html). LTO can produce better optimized code, using
whole-program analysis, at the cost of longer linking time.

See also the [`-C linker-plugin-lto`](https://doc.rust-lang.org/rustc/codegen-options/index.html#linker-plugin-lto) `rustc` flag for cross-language LTO.

enumValues: Performs "fat" LTO which attempts to perform optimizations across all crates within the dependency graph.

enumValues:
Performs ["thin" LTO](http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html). This is similar to "fat", but takes
substantially less time to run while still achieving performance gains
similar to "fat".

enumValues:
Performs "thin local LTO" which performs "thin" LTO on the local
crate only across its [codegen units](https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units). No LTO is performed
if codegen units is 1 or [opt-level](https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level) is 0.

title: Meta Build

title: Resolver

description:
A different feature resolver algorithm can be used by specifying the resolver version in Cargo.toml like this:

[package]
name = "my-package"
version = "1.0.0"
resolver = "2"

The version "1" resolver is the original resolver that shipped with Cargo up to version 1.50. The default is "2" if the root package specifies edition = "2021" or a newer edition. Otherwise the default is "1".

The version "2" resolver introduces changes in feature unification. See the features chapter for more details.

The resolver is a global option that affects the entire workspace. The resolver version in dependencies is ignored, only the value in the top-level package will be used. If using a virtual workspace, the version should be specified in the [workspace] table, for example:

[workspace]
members = ["member1", "member2"]
resolver = "2"

title: Optimization Level

description:
The `opt-level` setting controls the [`-C opt-level` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#opt-level) which controls the level
of optimization. Higher optimization levels may produce faster runtime code at
the expense of longer compiler times. Higher levels may also change and
rearrange the compiled code which may make it harder to use with a debugger.

It is recommended to experiment with different levels to find the right
balance for your project. There may be surprising results, such as level `3`
being slower than `2`, or the `"s"` and `"z"` levels not being necessarily
smaller. You may also want to reevaluate your settings over time as newer
versions of `rustc` changes optimization behavior.

See also [Profile Guided Optimization](https://doc.rust-lang.org/rustc/profile-guided-optimization.html) for more advanced optimization
techniques.

enumValues: No optimizations, also turns on [`cfg(debug_assertions)`](https://doc.rust-lang.org/cargo/reference/profiles.html#debug-assertions).

enumValues: Optimize for binary size, but also turn off loop vectorization.

title: Package

description:
The only fields required by Cargo are [`name`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-name-field) and
[`version`](https://doc.rust-lang.org/cargo/reference/manifest.html#the-version-field). If publishing to a registry, the registry may
require additional fields. See the notes below and [the publishing chapter](https://doc.rust-lang.org/cargo/reference/publishing.html) for requirements for publishing to [crates.io](https://crates.io/).

required: name version

$ref: #/definitions/Authors

$ref: #/definitions/WorkspaceInheritance

description:
Disable automatic discovery of `bench` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

description:
Disable automatic discovery of `bin` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

To prevent Cargo from inferring `src/bin/mod.rs` as an executable, set
this to `false` to disable auto-discovery.

description:
Disable automatic discovery of `example` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

description:
Disable automatic discovery of `test` targets.

Disabling automatic discovery should only be needed for specialized
situations. For example, if you have a library where you want a *module* named
`bin`, this would present a problem because Cargo would usually attempt to
compile anything in the `bin` directory as an executable. Here is a sample
layout of this scenario:

```
├── Cargo.toml
└── src
    ├── lib.rs
    └── bin
        └── mod.rs
```

$ref: #/definitions/Build

$ref: #/definitions/Categories

description:
The `default-run` field in the `[package]` section of the manifest can be used
to specify a default binary picked by [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html). For example, when there is
both `src/bin/a.rs` and `src/bin/b.rs`:

```toml
[package]
default-run = "a"
```

$ref: #/definitions/Description

$ref: #/definitions/Documentation

$ref: #/definitions/Edition

$ref: #/definitions/Exclude

$ref: #/definitions/Homepage

description: Sets whether the current package is a teapot or something else that is not capable of brewing tea.

$ref: #/definitions/Include

$ref: #/definitions/Keywords

$ref: #/definitions/License

$ref: #/definitions/LicenseFile

description:
The `links` field specifies the name of a native library that is being linked
to. More information can be found in the [`links`](https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key) section of the build
script guide.

```toml
[package]
# ...
links = "foo"
```

$ref: #/definitions/MetaBuild

description:
Cargo by default will warn about unused keys in `Cargo.toml` to assist in
detecting typos and such. The `package.metadata` table, however, is completely
ignored by Cargo and will not be warned about. This section can be used for
tools which would like to store package configuration in `Cargo.toml`. For
example:

```toml
[package]
name = "..."
# ...

# Metadata used when generating an Android APK, for example.
[package.metadata.android]
package-name = "my-awesome-android-app"
assets = "path/to/static"
```

description:
The package name is an identifier used to refer to the package. It is used
when listed as a dependency in another package, and as the default name of
inferred lib and bin targets.

The name must use only [alphanumeric](https://doc.rust-lang.org/std/primitive.char.html#method.is_alphanumeric) characters or `-` or `_`, and cannot be empty.
Note that [`cargo new`](https://doc.rust-lang.org/cargo/commands/cargo-new.html) and [`cargo init`](https://doc.rust-lang.org/cargo/commands/cargo-init.html) impose some additional restrictions on
the package name, such as enforcing that it is a valid Rust identifier and not
a keyword. [crates.io](https://crates.io) imposes even more restrictions, such as
enforcing only ASCII characters, not a reserved name, not a special Windows
name such as "nul", is not too long, etc.

$ref: #/definitions/Publish

$ref: #/definitions/Readme

$ref: #/definitions/Repository

$ref: #/definitions/Resolver

$ref: #/definitions/RustVersion

$ref: #/definitions/SemVer

description:
The `workspace` field can be used to configure the workspace that this package
will be a member of. If not specified this will be inferred as the first
Cargo.toml with `[workspace]` upwards in the filesystem. Setting this is
useful if the member is not inside a subdirectory of the workspace root.

```toml
[package]
# ...
workspace = "path/to/workspace/root"
```

This field cannot be specified if the manifest already has a `[workspace]`
table defined. That is, a crate cannot both be a root crate in a workspace
(contain `[workspace]`) and also be a member crate of another workspace
(contain `package.workspace`).

For more information, see the [workspaces chapter](https://doc.rust-lang.org/cargo/reference/workspaces.html).

title: Panic

description:
The `panic` setting controls the [`-C panic` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#panic) which controls which panic
strategy to use.

When set to `"unwind"`, the actual value depends on the default of the target
platform. For example, the NVPTX platform does not support unwinding, so it
always uses `"abort"`.

Tests, benchmarks, build scripts, and proc macros ignore the `panic` setting.
The `rustc` test harness currently requires `unwind` behavior. See the
[`panic-abort-tests`](https://doc.rust-lang.org/cargo/reference/unstable.html#panic-abort-tests) unstable flag which enables `abort` behavior.

Additionally, when using the `abort` strategy and building a test, all of the
dependencies will also be forced to built with the `unwind` strategy.

enum: unwind abort

enumValues:
Unwind the stack upon panic.
Terminate the process upon panic.

title: Platform

description:
You can depend on other Cargo-based crates for use in your build scripts.
Dependencies are declared through the `build-dependencies` section of the
manifest:

```toml
[build-dependencies]
cc = "1.0.3"
```

The build script **does not** have access to the dependencies listed
in the `dependencies` or `dev-dependencies` section. Build
dependencies will likewise not be available to the package itself
unless listed under the `dependencies` section as well. A package
itself and its build script are built separately, so their
dependencies need not coincide. Cargo is kept simpler and cleaner by
using independent dependencies for independent purposes.

$ref: #/definitions/Dependency

schemas: dependencies

description:
Cargo is configured to look for dependencies on [crates.io](https://crates.io) by default. Only
the name and a version string are required in this case. In [the cargo
guide](https://doc.rust-lang.org/cargo/guide/index.html), we specified a dependency on the `time` crate:

```toml
[dependencies]
time = "0.1.12"
```

The string `"0.1.12"` is a [semver](https://github.com/steveklabnik/semver#requirements) version requirement. Since this
string does not have any operators in it, it is interpreted the same way as
if we had specified `"^0.1.12"`, which is called a caret requirement.

A dependency can also be defined by a table with additional options:

```toml
[dependencies]
time = { path = "../time", version = "0.1.12" }
```

description:
The format of `[dev-dependencies]` is equivalent to `[dependencies]`:

```toml
[dev-dependencies]
tempdir = "0.3"
```

Dev-dependencies are not used when compiling
a package for building, but are used for compiling tests, examples, and
benchmarks.

These dependencies are *not* propagated to other packages which depend on this
package.

You can also have target-specific development dependencies by using
`dev-dependencies` in the target section header instead of `dependencies`. For
example:

```toml
[target.'cfg(unix)'.dev-dependencies]
mio = "0.0.1"
```

> **Note**: When a package is published, only dev-dependencies that specify a
> `version` will be included in the published crate. For most use cases,
> dev-dependencies are not needed when published, though some users (like OS
> packagers) may want to run tests within a crate, so providing a `version` if
> possible can still be beneficial.

title: Build Override

description:
Profile settings can be overridden for specific packages and build-time
crates. To override the settings for a specific package, use the `package`
table to change the settings for the named package:

```toml
# The `foo` package will use the -Copt-level=3 flag.
[profile.dev.package.foo]
opt-level = 3
```

The package name is actually a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as
`[profile.dev.package."foo:2.1.0"]`.

To override the settings for all dependencies (but not any workspace member),
use the `"*"` package name:

```toml
# Set the default for dependencies.
[profile.dev.package."*"]
opt-level = 2
```

To override the settings for build scripts, proc macros, and their
dependencies, use the `build-override` table:

```toml
# Set the settings for build scripts and proc-macros.
[profile.dev.build-override]
opt-level = 3
```

> Note: When a dependency is both a normal dependency and a build dependency,
> Cargo will try to only build it once when `--target` is not specified. When
> using `build-override`, the dependency may need to be built twice, once as a
> normal dependency and once with the overridden build settings. This may
> increase initial build times.

$ref: #/definitions/Profile

title: Profile

description:
The `codegen-units` setting controls the [`-C codegen-units` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#codegen-units) which
controls how many "code generation units" a crate will be split into. More
code generation units allows more of a crate to be processed in parallel
possibly reducing compile time, but may produce slower code.

This option takes an integer greater than 0.

The default is 256 for [incremental](https://doc.rust-lang.org/cargo/reference/profiles.html#incremental) builds, and 16 for
non-incremental builds.

type: integer

$ref: #/definitions/DebugLevel

description:
The `debug-assertions` setting controls the [`-C debug-assertions` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#debug-assertions) which
turns `cfg(debug_assertions)` [conditional compilation](https://doc.rust-lang.org/reference/conditional-compilation.html#debug_assertions) on or off. Debug
assertions are intended to include runtime validation which is only available
in debug/development builds. These may be things that are too expensive or
otherwise undesirable in a release build. Debug assertions enables the
[`debug_assert!` macro](https://doc.rust-lang.org/std/macro.debug_assert.html) in the standard library.

description:
The `incremental` setting controls the [`-C incremental` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#incremental) which controls
whether or not incremental compilation is enabled. Incremental compilation
causes `rustc` to to save additional information to disk which will be reused
when recompiling the crate, improving re-compile times. The additional
information is stored in the `target` directory.

The valid options are:

* `true`: enabled
* `false`: disabled

Incremental compilation is only used for workspace members and "path"
dependencies.

The incremental value can be overridden globally with the `CARGO_INCREMENTAL`
[environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html) or the [`build.incremental`](https://doc.rust-lang.org/cargo/reference/config.html#buildincremental) config variable.

description:
The `overflow-checks` setting controls the [`-C overflow-checks` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#overflow-checks) which
controls the behavior of [runtime integer overflow](https://doc.rust-lang.org/reference/expressions/operator-expr.html#overflow). When overflow-checks are
enabled, a panic will occur on overflow.

description:
Package-specific overrides.

The package name is a [Package ID Spec](https://doc.rust-lang.org/cargo/reference/pkgid-spec.html), so you can
target individual versions of a package with syntax such as `[profile.dev.package."foo:2.1.0"]`.

description:
The `rpath` setting controls the [`-C rpath` flag](https://doc.rust-lang.org/rustc/codegen-options/index.html#rpath) which controls
whether or not [`rpath`](https://en.wikipedia.org/wiki/Rpath) is enabled.

title: Profiles

description:
Profiles provide a way to alter the compiler settings, influencing things like optimizations and debugging symbols.

Cargo has 4 built-in profiles: dev, release, test, and bench. It automatically chooses the profile based on which command is being run, the package and target that is being built, and command-line flags like --release.

title: Publish

description:
The `publish` field can be used to prevent a package from being published to a package registry (like *crates.io*) by mistake, for instance to keep a package
private in a company.

```toml
[package]
# ...
publish = false
```

The value may also be an array of strings which are registry names that are
allowed to be published to.

```toml
[package]
# ...
publish = ["some-registry-name"]
```

description: A boolean indicating whether the package can be published.

enumValues:
The package can be published.
The package cannot be published.

description: An array of registry names.

title: Readme

description:
The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.
This file will be transferred to the registry when you publish. [crates.io](https://crates.io)
will interpret it as Markdown and render it on the crate's page.

```toml
[package]
# ...
readme = "README.md"
```

If no value is specified for this field, and a file named `README.md`,
`README.txt` or `README` exists in the package root, then the name of that
file will be used. You can suppress this behavior by setting this field to
`false`. If the field is set to `true`, a default value of `README.md` will
be assumed.

description:
The `readme` field should be the path to a file in the package root (relative
to this `Cargo.toml`) that contains general information about the package.

enumValues:
Use the `README.md` file.
Do not use the default `README.md` file

title: Semantic Version

description:
Cargo bakes in the concept of [Semantic Versioning](https://semver.org/), so make sure you follow some basic rules:

* Before you reach 1.0.0, anything goes, but if you make breaking changes,
    increment the minor version. In Rust, breaking changes include adding fields to
    structs or variants to enums.
* After 1.0.0, only make breaking changes when you increment the major version.
    Don't break the build.
* After 1.0.0, don't add any new public API (no new `pub` anything) in patch-level
    versions. Always increment the minor version if you add any new `pub` structs,
    traits, fields, types, functions, methods or anything else.
* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

title: Semantic Version Requirement

description: The [version requirement](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) of the target dependency.

title: Target

description:
The `bench` field indicates whether or not the target is benchmarked by
default by [`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html). The default is `true` for lib, bins, and
benchmarks.

description:
The `crate-type` field defines the [crate types](https://doc.rust-lang.org/reference/linkage.html) that will be generated by the
target. It is an array of strings, allowing you to specify multiple crate
types for a single target. This can only be specified for libraries and
examples. Binaries, tests, and benchmarks are always the "bin" crate type.

The available options are `bin`, `lib`, `rlib`, `dylib`, `cdylib`,
`staticlib`, and `proc-macro`. You can read more about the different crate
types in the [Rust Reference Manual](https://doc.rust-lang.org/reference/linkage.html).

enumValues:
A runnable executable will be produced. This requires that there is a `main` function in the crate which
will be run when the program begins executing. This will link in all Rust and
native dependencies, producing a distributable binary.

enumValues:
A Rust library will be produced.
This is an ambiguous concept as to what exactly is produced because a library
can manifest itself in several forms. The purpose of this generic `lib` option
is to generate the "compiler recommended" style of library. The output library
will always be usable by rustc, but the actual type of library may change from
time-to-time. The remaining output types are all different flavors of
libraries, and the `lib` type can be seen as an alias for one of them (but the
actual one is compiler-defined).

enumValues:
A "Rust library" file will be produced. This is used as an intermediate artifact and can be thought of as a
"static Rust library". These `rlib` files, unlike `staticlib` files, are
interpreted by the compiler in future linkage. This essentially means
that `rustc` will look for metadata in `rlib` files like it looks for metadata
in dynamic libraries. This form of output is used to produce statically linked
executables as well as `staticlib` outputs.

enumValues:
A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces
dynamic library generation. The resulting dynamic library can be used as a
dependency for other libraries and/or executables. This output type will
create `*.so` files on linux, `*.dylib` files on osx, and `*.dll` files on
windows.

enumValues:
A dynamic system library will be produced. This is used when compiling
a dynamic library to be loaded from another language.  This output type will
create `*.so` files on Linux, `*.dylib` files on macOS, and `*.dll` files on
Windows.

enumValues:
A static system library will be produced. This is different from other library outputs in that
the compiler will never attempt to link to `staticlib` outputs. The
purpose of this output type is to create a static library containing all of
the local crate's code along with all upstream dependencies. The static
library is actually a `*.a` archive on linux and osx and a `*.lib` file on
windows. This format is recommended for use in situations such as linking
Rust code into an existing non-Rust application because it will not have
dynamic dependencies on other Rust code.

enumValues:
The output produced is not specified, but if a `-L` path is provided to it then the
compiler will recognize the output artifacts as a macro and it can be loaded
for a program. Crates compiled with this crate type  must only export
[procedural macros](https://doc.rust-lang.org/reference/procedural-macros.html). The compiler will automatically set the `proc_macro`
[configuration option](https://doc.rust-lang.org/reference/conditional-compilation.html). The crates are always compiled with the same target
that the compiler itself was built with. For example, if you are executing
the compiler from Linux with an `x86_64` CPU, the target will be
`x86_64-unknown-linux-gnu` even if the crate is a dependency of another crate
being built for a different target.

description:
The `doc` field indicates whether or not the target is included in the
documentation generated by [`cargo doc`](https://doc.rust-lang.org/cargo/commands/cargo-doc.html) by default. The default is `true` for
libraries and binaries.

> **Note**: The binary will be skipped if its name is the same as the lib
> target.

description:
The `doctest` field indicates whether or not [documentation examples](https://doc.rust-lang.org/rustdoc/documentation-tests.html) are
tested by default by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). This is only relevant for libraries, it
has no effect on other sections. The default is `true` for the library.

description:
The `harness` field indicates that the [`--test` flag](https://doc.rust-lang.org/rustc/command-line-arguments.html#option-test) will be passed to
`rustc` which will automatically include the libtest library which is the
driver for collecting and running tests marked with the [`#[test]` attribute](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) or benchmarks with the `#[bench]` attribute. The
default is `true` for all targets.

If set to `false`, then you are responsible for defining a `main()` function
to run tests and benchmarks.

Tests have the [`cfg(test)` conditional expression](https://doc.rust-lang.org/reference/conditional-compilation.html#test) enabled whether
or not the harness is enabled.

description:
The `name` field specifies the name of the target, which corresponds to the
filename of the artifact that will be generated. For a library, this is the
crate name that dependencies will use to reference it.

For the `[lib]` and the default binary (`src/main.rs`), this defaults to the
name of the package, with any dashes replaced with underscores. For other
[auto discovered](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) targets, it defaults to the
directory or file name.

This is required for all targets except `[lib]`.

description:
The `path` field specifies where the source for the crate is located, relative
to the `Cargo.toml` file.

If not specified, the [inferred path](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#target-auto-discovery) is used based on
the target name.

description:
The `proc-macro` field indicates that the library is a [procedural macro](https://doc.rust-lang.org/book/ch19-06-macros.html)
([reference](https://doc.rust-lang.org/reference/procedural-macros.html)). This is only valid for the `[lib]`
target.

description:
The `required-features` field specifies which [features](https://doc.rust-lang.org/cargo/reference/features.html) the target needs in
order to be built. If any of the required features are not enabled, the
target will be skipped. This is only relevant for the `[[bin]]`, `[[bench]]`,
`[[test]]`, and `[[example]]` sections, it has no effect on `[lib]`.

```toml
[features]
# ...
postgres = []
sqlite = []
tools = []

[[bin]]
name = "my-pg-tool"
required-features = ["postgres", "tools"]
```

description:
The `test` field indicates whether or not the target is tested by default by
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html). The default is `true` for lib, bins, and tests.

> **Note**: Examples are built by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by default to ensure they
> continue to compile, but they are not *tested* by default. Setting `test =
> true` for an example will also build it as a test and run any
> [`#[test]`](https://doc.rust-lang.org/reference/attributes/testing.html#the-test-attribute) functions defined in the example.

title: Workspace

description:
The `[workspace]` table in `Cargo.toml` defines which packages are members of
the workspace:

```toml
[workspace]
members = ["member1", "path/to/member2", "crates/*"]
exclude = ["crates/foo", "path/to/other"]
```

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

All [`path` dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies) residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs](https://docs.rs/glob/0.3.0/glob/struct.Pattern.html) to match multiple paths, using
typical filename glob patterns like `*` and `?`.

The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

An empty `[workspace]` table can be used with a `[package]` to conveniently
create a workspace with the package and all of its path dependencies.

description:
The optional `default-members` key can be specified to set the members to
operate on when in the workspace root and the package selection flags are not
used:

```toml
[workspace]
members = ["path/to/member1", "path/to/member2", "path/to/member3/*"]
default-members = ["path/to/member2", "path/to/member3/foo"]
```

When specified, `default-members` must expand to a subset of `members`.

description:
The `workspace.dependencies` table is where you define dependencies to be
inherited by members of a workspace.

Specifying a workspace dependency is similar to [package dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) except:
- Dependencies from this table cannot be declared as `optional`
- [`features`][features] declared in this table are additive with the `features` from `[dependencies]`

You can then [inherit the workspace dependency as a package dependency](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace)

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.dependencies]
cc = "1.0.73"
rand = "0.8.5"
regex = { version = "1.6.0", default-features = false, features = ["std"] }
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version = "0.2.0"

[dependencies]
regex = { workspace = true, features = ["unicode"] }

[build-dependencies]
cc.workspace = true

[dev-dependencies]
rand.workspace = true
```

description:
The `exclude` key can be used to prevent paths from being included in a
workspace. This can be useful if some path dependencies aren't desired to be
in the workspace at all, or using a glob pattern and you want to remove a
directory.

description:
All [`path` dependencies] residing in the workspace directory automatically
become members. Additional members can be listed with the `members` key, which
should be an array of strings containing directories with `Cargo.toml` files.

The `members` list also supports [globs] to match multiple paths, using
typical filename glob patterns like `*` and `?`.

description:
The `workspace.metadata` table is ignored by Cargo and will not be warned
about. This section can be used for tools that would like to store workspace
configuration in `Cargo.toml`. For example:

```toml
[workspace]
members = ["member1", "member2"]

[workspace.metadata.webcontents]
root = "path/to/webproject"
tool = ["npm", "run", "build"]
# ...
```

There is a similar set of tables at the package level at
`package.metadata`. While cargo does not specify a
format for the content of either of these tables, it is suggested that
external tools may wish to use them in a consistent fashion, such as referring
to the data in `workspace.metadata` if data is missing from `package.metadata`,
if that makes sense for the tool in question.

description:
The `workspace.package` table is where you define keys that can be
inherited by members of a workspace. These keys can be inherited by
defining them in the member package with `{key}.workspace = true`.

Keys that are supported:

|                |                 |
|----------------|-----------------|
| `authors`      | `categories`    |
| `description`  | `documentation` |
| `edition`      | `exclude`       |
| `homepage`     | `include`       |
| `keywords`     | `license`       |
| `license-file` | `publish`       |
| `readme`       | `repository`    |
| `rust-version` | `version`       |

- `license-file` and `readme` are relative to the workspace root
- `include` and `exclude` are relative to your package root

Example:
```toml
# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.package]
version = "1.2.3"
authors = ["Nice Folks"]
description = "A short description of my package"
documentation = "https://example.com/bar"
```

```toml
# [PROJECT_DIR]/bar/Cargo.toml
[package]
name = "bar"
version.workspace = true
authors.workspace = true
description.workspace = true
documentation.workspace = true
```

title: Authors

description:
The `authors` field lists people or organizations that are considered the
"authors" of the package. The exact meaning is open to interpretation — it may
list the original or primary authors, current maintainers, or owners of the
package. These names will be listed on the crate's page on
[crates.io](https://crates.io). An optional email address may be included within angled
brackets at the end of each author.

> **Note**: [crates.io](https://crates.io) requires at least one author to be listed.

title: Categories

description:
The `categories` field is an array of strings of the categories this package
belongs to.

```toml
categories = ["command-line-utilities", "development-tools::cargo-plugins"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 categories. Each category should
> match one of the strings available at https://crates.io/category_slugs, and
> must match exactly.

title: Description

description:
The description is a short blurb about the package. [crates.io](https://crates.io) will display
this with your package. This should be plain text (not Markdown).

```toml
[package]
# ...
description = "A short description of my package"
```

> **Note**: [crates.io](https://crates.io) requires the `description` to be set.

title: Documentation

description:
The `documentation` field specifies a URL to a website hosting the crate's
documentation. If no URL is specified in the manifest file, [crates.io](https://crates.io) will
automatically link your crate to the corresponding [docs.rs](https://docs.rs) page.

```toml
[package]
# ...
documentation = "https://docs.rs/bitflags"
```

title: Exclude

description:
You can explicitly specify that a set of file patterns should be ignored or
included for the purposes of packaging. The patterns specified in the
`exclude` field identify a set of files that are not included, and the
patterns in `include` specify files that are explicitly included.

The patterns should be [gitignore](https://git-scm.com/docs/gitignore)-style patterns. Briefly:

- `foo` matches any file or directory with the name `foo` anywhere in the
  package. This is equivalent to the pattern `**/foo`.
- `/foo` matches any file or directory with the name `foo` only in the root of
  the package.
- `foo/` matches any *directory* with the name `foo` anywhere in the package.
- Common glob patterns like `*`, `?`, and `[]` are supported:
  - `*` matches zero or more characters except `/`.  For example, `*.html`
    matches any file or directory with the `.html` extension anywhere in the
    package.
  - `?` matches any character except `/`. For example, `foo?` matches `food`,
    but not `foo`.
  - `[]` allows for matching a range of characters. For example, `[ab]`
    matches either `a` or `b`. `[a-z]` matches letters a through z.
- `**/` prefix matches in any directory. For example, `**/foo/bar` matches the
  file or directory `bar` anywhere that is directly under directory `foo`.
- `/**` suffix matches everything inside. For example, `foo/**` matches all
  files inside directory `foo`, including all files in subdirectories below
  `foo`.
- `/**/` matches zero or more directories. For example, `a/**/b` matches
  `a/b`, `a/x/b`, `a/x/y/b`, and so on.
- `!` prefix negates a pattern. For example, a pattern of `src/**.rs` and
  `!foo.rs` would match all files with the `.rs` extension inside the `src`
  directory, except for any file named `foo.rs`.

If git is being used for a package, the `exclude` field will be seeded with
the `gitignore` settings from the repository.

```toml
[package]
# ...
exclude = ["build/**/*.o", "doc/**/*.html"]
```

```toml
[package]
# ...
include = ["src/**/*", "Cargo.toml"]
```

The options are mutually exclusive: setting `include` will override an
`exclude`. Note that `include` must be an exhaustive list of files as otherwise
necessary source files may not be included. The package's `Cargo.toml` is
automatically included.

The include/exclude list is also used for change tracking in some situations.
For targets built with `rustdoc`, it is used to determine the list of files to
track to determine if the target should be rebuilt. If the package has a
[build script](https://doc.rust-lang.org/cargo/reference/build-scripts.html) that does not emit any `rerun-if-*` directives, then the
include/exclude list is used for tracking if the build script should be re-run
if any of those files change.

title: Homepage

description:
The `homepage` field should be a URL to a site that is the home page for your
package.

```toml
[package]
# ...
homepage = "https://serde.rs/"
```

title: Keywords

description:
The `keywords` field is an array of strings that describe this package. This
can help when searching for the package on a registry, and you may choose any
words that would help someone find this crate.

```toml
[package]
# ...
keywords = ["gamedev", "graphics"]
```

> **Note**: [crates.io](https://crates.io) has a maximum of 5 keywords. Each keyword must be
> ASCII text, start with a letter, and only contain letters, numbers, `_` or
> `-`, and have at most 20 characters.

title: License

description:
The `license` field contains the name of the software license that the package
is released under.

[crates.io](https://crates.io/) interprets the `license` field as an [SPDX 2.1 license
expression](https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60). The name must be a known license
from the [SPDX license list 3.6](https://github.com/spdx/license-list-data/tree/v3.6). Parentheses are not
currently supported. See the [SPDX site](https://spdx.org/license-list) for more information.

SPDX license expressions support AND and OR operators to combine multiple
licenses.

```toml
[package]
# ...
license = "MIT OR Apache-2.0"
```

Using `OR` indicates the user may choose either license. Using `AND` indicates
the user must comply with both licenses simultaneously. The `WITH` operator
indicates a license with a special exception. Some examples:

* `MIT OR Apache-2.0`
* `LGPL-2.1 AND MIT AND BSD-2-Clause`
* `GPL-2.0+ WITH Bison-exception-2.2`

If a package is using a nonstandard license, then the `license-file` field may
be specified in lieu of the `license` field.

title: LicenseFile

description:
The `license-file` field contains the path to a file
containing the text of the license (relative to this `Cargo.toml`).

```toml
[package]
# ...
license-file = "LICENSE.txt"
```

> **Note**: [crates.io](https://crates.io) requires either `license` or `license-file` to be set.

title: Repository

description:
The `repository` field should be a URL to the source repository for your
package.

```toml
[package]
# ...
repository = "https://github.com/rust-lang/cargo/"
```

title: RustVersion

description:
The `rust-version` field is an optional key that tells cargo what version of the
Rust language and compiler your package can be compiled with. If the currently
selected version of the Rust compiler is older than the stated version, cargo
will exit with an error, telling the user what version is required.

The first version of Cargo that supports this field was released with Rust 1.56.0.
In older releases, the field will be ignored, and Cargo will display a warning.

```toml
[package]
# ...
rust-version = "1.56"
```

The Rust version must be a bare version number with two or three components; it
cannot include semver operators or pre-release identifiers. Compiler pre-release
identifiers such as -nightly will be ignored while checking the Rust version.
The `rust-version` must be equal to or newer than the version that first
introduced the configured `edition`.

The `rust-version` may be ignored using the `--ignore-rust-version` option.

Setting the `rust-version` key in `[package]` will affect all targets/crates in
the package, including test suites, benchmarks, binaries, examples, etc.

title: Workspace

description: The `workspace` field allow keys to be inherited by defining them in the member package with `{key}.workspace = true`

description: A schema for Cargo.toml.

description:
[crates.io](https://crates.io) can display various badges for build status, test coverage, etc. for
each crate. All badges are optional.

- The badges pertaining to build status that are currently available are
  Appveyor, CircleCI, Cirrus CI, GitLab, Azure DevOps, Travis CI and Bitbucket
  Pipelines.
- Available badges pertaining to code test coverage are Codecov and Coveralls.
- There are also maintenance-related badges based on isitmaintained.com
  which state the issue resolution time, percent of open issues, and future
  maintenance intentions.

Most badge specifications require a `repository` key. It is expected to be in
`user/repo` format.

```toml
[badges]

# Appveyor: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`; `id` is optional; you can specify the appveyor project id if you
# want to use that instead. `project_name` is optional; use when the repository
# name differs from the appveyor project name.
appveyor = { repository = "...", branch = "master", service = "github" }

# Circle CI: `repository` is required. `branch` is optional; default is `master`
circle-ci = { repository = "...", branch = "master" }

# Cirrus CI: `repository` is required. `branch` is optional; default is `master`
cirrus-ci = { repository = "...", branch = "master" }

# GitLab: `repository` is required. `branch` is optional; default is `master`
gitlab = { repository = "...", branch = "master" }

# Azure DevOps: `project` is required. `pipeline` is required. `build` is optional; default is `1`
# Note: project = `organization/project`, pipeline = `name_of_pipeline`, build = `definitionId`
azure-devops = { project = "...", pipeline = "...", build="2" }

# Travis CI: `repository` in format "<user>/<project>" is required.
# `branch` is optional; default is `master`
travis-ci = { repository = "...", branch = "master" }

# Bitbucket Pipelines: `repository` is required. `branch` is required
bitbucket-pipelines = { repository = "...", branch = "master" }

# Codecov: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default), `bitbucket`, and
# `gitlab`.
codecov = { repository = "...", branch = "master", service = "github" }

# Coveralls: `repository` is required. `branch` is optional; default is `master`
# `service` is optional; valid values are `github` (default) and `bitbucket`.
coveralls = { repository = "...", branch = "master", service = "github" }

# Is it maintained resolution time: `repository` is required.
is-it-maintained-issue-resolution = { repository = "..." }

# Is it maintained percentage of open issues: `repository` is required.
is-it-maintained-open-issues = { repository = "..." }

# Maintenance: `status` is required. Available options are:
# - `actively-developed`: New features are being added and bugs are being fixed.
# - `passively-maintained`: There are no plans for new features, but the maintainer intends to
#   respond to issues that get filed.
# - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on
#   it or providing support, but it works for the purposes it was designed for.
# - `experimental`: The author wants to share it with the community but is not intending to meet
#   anyone's particular use case.
# - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone
#   else.
# - `deprecated`: The maintainer does not recommend using this crate (the description of the crate
#   can describe why, there could be a better solution available or there could be problems with
#   the crate that the author does not want to fix).
# - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify
#   their intentions, potential crate users will need to investigate on their own.
maintenance = { status = "..." }
```

description:
Benchmarks provide a way to test the performance of your code using the
[`cargo bench`](https://doc.rust-lang.org/cargo/commands/cargo-bench.html) command. They follow the same structure as [tests](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#tests),
with each benchmark function annotated with the `#[bench]` attribute.
Similarly to tests:

* Benchmarks are placed in the [`benches` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html).
* Benchmark functions defined in libraries and binaries have access to the
  *private* API within the target they are defined in. Benchmarks in the
  `benches` directory may use the *public* API.
* [The `bench` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-bench-field) can be used to define which targets
  are benchmarked by default.
* [The `harness` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-harness-field) can be used to disable the
  built-in harness.

> **Note**: The [`#[bench]`
> attribute](https://doc.rust-lang.org/unstable-book/library-features/test.html) is currently
> unstable and only available on the [nightly channel](https://doc.rust-lang.org/book/appendix-07-nightly-rust.html). There are some
> packages available on [crates.io](https://crates.io/keywords/benchmark) that
> may help with running benchmarks on the stable channel, such as
> [Criterion](https://crates.io/crates/criterion).

description:
Binary targets are executable programs that can be run after being compiled.
The default binary filename is `src/main.rs`, which defaults to the name of
the package. Additional binaries are stored in the [`src/bin/`
directory](https://doc.rust-lang.org/cargo/guide/project-layout.html). The settings for each binary can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[[bin]]` tables in `Cargo.toml`.

Binaries can use the public API of the package's library. They are also linked
with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) defined in `Cargo.toml`.

You can run individual binaries with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with the `--bin
<bin-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html) can be used to copy the executable to a
common location.

```toml
# Example of customizing binaries in Cargo.toml.
[[bin]]
name = "cool-tool"
test = false
bench = false

[[bin]]
name = "frobnicator"
required-features = ["frobnicate"]
```

description:
Files located under the [examples directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are example uses of the functionality provided by the library. When compiled, they are placed in the[ target/debug/examples directory](https://doc.rust-lang.org/cargo/guide/build-cache.html).

Examples can use the public API of the package's library. They are also linked with the [dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and [dev-dependencies](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in Cargo.toml.

By default, examples are executable binaries (with a `main()` function). You
can specify the [`crate-type` field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-crate-type-field) to make an example
be compiled as a library:

```toml
[[example]]
name = "foo"
crate-type = ["staticlib"]
```

You can run individual executable examples with the [`cargo run`](https://doc.rust-lang.org/cargo/commands/cargo-run.html) command with
the `--example <example-name>` option. Library examples can be built with
[`cargo build`](https://doc.rust-lang.org/cargo/commands/cargo-build.html) with the `--example <example-name>` option. [`cargo install`](https://doc.rust-lang.org/cargo/commands/cargo-install.html)
with the `--example <example-name>` option can be used to copy executable
binaries to a common location. Examples are compiled by [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) by
default to protect them from bit-rotting. Set [the `test`
field](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#the-test-field) to `true` if you have `#[test]` functions in the
example that you want to run with [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html).

description:
Cargo supports features to allow expression of:

* conditional compilation options (usable through `cfg` attributes);
* optional dependencies, which enhance a package, but are not required; and
* clusters of optional dependencies, such as `postgres-all`, that would include the
  `postgres` package, the `postgres-macros` package, and possibly other packages
  (such as development-time mocking libraries, debugging tools, etc.).

A feature of a package is either an optional dependency, or a set of other
features.

main:
The library target defines a "library" that can be used and linked by other
libraries and executables. The filename defaults to `src/lib.rs`, and the name
of the library defaults to the name of the package. A package can have only
one library. The settings for the library can be [customized](https://doc.rust-lang.org/cargo/reference/cargo-targets.html#configuring-a-target) in the `[lib]`
table in `Cargo.toml`.

```toml
# Example of customizing the library in Cargo.toml.
[lib]
crate-type = ["cdylib"]
bench = false
```

description:
The `[patch]` section of `Cargo.toml` can be used to override dependencies
with other copies. The syntax is similar to the
[`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) section.

description:
Files located under the [`tests` directory](https://doc.rust-lang.org/cargo/guide/project-layout.html) are integration
tests. When you run [`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html), Cargo will compile each of these files as
a separate crate, and execute them.

Integration tests can use the public API of the package's library. They are
also linked with the [`[dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html) and
[`[dev-dependencies]`](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#development-dependencies) defined in `Cargo.toml`.

If you want to share code among multiple integration tests, you can place it
in a separate module such as `tests/common/mod.rs` and then put `mod common;`
in each test to import it.

Each integration test results in a separate executable binary, and [`cargo
test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) will run them serially. In some cases this can be inefficient, as it
can take longer to compile, and may not make full use of multiple CPUs when
running the tests. If you have a lot of integration tests, you may want to
consider creating a single integration test, and split the tests into multiple
modules. The libtest harness will automatically find all of the `#[test]`
annotated functions and run them in parallel. You can pass module names to
[`cargo test`](https://doc.rust-lang.org/cargo/commands/cargo-test.html) to only run the tests within that module.

Binary targets are automatically built if there is an integration test. This
allows an integration test to execute the binary to exercise and test its
behavior. The `CARGO_BIN_EXE_<name>` [environment variable](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates) is set when the
integration test is built so that it can use the [`env` macro](https://doc.rust-lang.org/std/macro.env.html) to locate the
executable.

title: Cargo.toml


description: Schema to validate Android JSON files given as input to DL-Config to generate Scan2Deploy barcodes

$id: #/properties/layout

title: Layout Schema

title: Description Schema

$id: #/properties/layout/properties/enroll

title: Enroll Schema

$id: #/properties/padlock

title: Padlock Schema

description: Section used to configure the staging locking feature

title: Valid-Until Schema

description: Specifies the expiration date of the barcode sequence. Device date must be synchronized/configured for expiration date to work properly.

$id: #/properties/padlock/properties/key

title: Key Schema

description: Padlock key to be used. If value doesn't match the device, the barcode is rejected. Empty string means no key.

$id: #/properties/padlock/properties/state

enum: locked unlocked

title: State Schema

description: Configures the padlock state

default: undefined

title: Hide-From-Launcher Schema

description: Indicates if Scan2Deploy should be disabled after staging is complete. Once disabled, factory reset required to reenable.

$id: #/properties/global

title: Global Schema

description: Section used to configure application scoped settings

title: Target-Path Schema

description: Base destination folder where any archive/fill will be inflated/written. Default is device internal SD-card root

title: Install-Path Schema

description: Folder where the application expects auto-installed/auto-updated APKs to be found. Default is value specified in 'target path'.

title: Update-Path Schema

description: Folder where the application expects auto-updated OTA packages to be found. Default is value specified in 'target path'.

title: Purge-Target-Path Schema

description: Indicates if target specified in 'target-path' needs to be purged (deleted) prior to inflation of the deployment archive

title: Auto-Scan Schema

description: Enables/Disables the auto-update of APKs and OTA packages

title: Download-Preinstalled Schema

description: Used to force the downgrade of pre-installed application (even System app), if required

$id: #/properties/global/properties/script

type: string array

title: Script Schema

description: A string specifying the absolute/relative path of a file, or a JSON array of strings describing the file content line-by-line. The script file will be interpreted last in staging process.

title: Items Schema

examples: SHELL am start -a android.intent.action.MAIN -n com.example.mchew.fakeapp/.MainActivity

$id: #/properties/global/properties/action

enum: none close enterprise-reset factory-reset reset

title: Action Schema

description: Specifies the final action performed by the application at the end of the staging process.

title: Backup-To-Enterprise Schema

description: Activates the enterprise backup persistence for the staging data, resulting in both the staging script and archive being copied to the enterprise partition

$id: #/properties/settings

title: Settings Schema

description: Section used to control inner device settings that typically need to be changed from the Android defaults

title: Date-Time Schema

description: String representation in RFC-1123 format of the date to be set

title: Auto-Time Schema

description: Controls the 'Date & Time' automatic date-time adjustment setting

title: Auto-Time-Zone Schema

description: Controls the 'Date & Time' automatic time-zone adjustment setting

title: Auto-Time-Server Schema

description: Address of the NTP server to be used for date-time synchronization

title: Debug-Bridge Schema

description: Controls the state of 'Android Debug Bridge'

title: Lock-Screen Schema

description: Controls the state of Android's lock-screen, requiring the user to swipe the display to unlock the device

title: Status-Bar Schema

description: Controls the display of the top status-bar. Note: hiding the status-bar will make notification disappear.

title: Navigation-Bar Schema

description: Controls the display of the bottom navigation-bar

title: Charge-Threshold Schema

description: Indicates the charge threshold a battery exhausted device needs to reach to automatically boot when recharging

enum: NONE BOTH DATA CHARGE

title: Usb-Profile Schema

description: USB communication profile in use

default: BOTH

enum: MTP PTP CHARGING

title: Usb-Function Schema

description: USB communication function in use

default: CHARGING

$id: #/properties/network

title: Network Schema

description: Section used to configure the device Wi-Fi network

$id: #/properties/network/properties/essid

title: Essid Schema

description: Wireless network ESSID

default: tsunami

$id: #/properties/network/properties/hidden

title: Hidden Schema

description: Indicates if the wireless network is using a hidden ESSID

$id: #/properties/network/properties/mode

title: Mode Schema

description: Wireless connection mode

default: open

title: Mode-Key Schema

description: Wireless network key, if needed

title: Mode-Key-Encrypted Schema

description: Indicates if 'mode-key' is written in plain-text or encrypted with a custom encryption algorithm

enum: none peap tls ttls pwd sim aka aka-prime

title: Eap-Method Schema

description: Configures the EAP authentication method

enum: none pap mschap mschapv2 gtc

title: Eap-Phase2 Schema

description: Configures the EAP phase 2 authentication method

title: Eap-Identity Schema

description: Indicates the EAP identity

title: Eap-Anonymous-Identity Schema

description: Indicates the EAP anonymous identity, used as the unencrypted identity with certain EAP types

title: Eap-Password Schema

description: EAP password, if needed

title: Eap-Password-Encrypted Schema

description: Indicates if the 'eap-password' is encrypted with a custom encryption algorithm

title: Eap-Certificate Schema

description: Base64 representation of the EAP certificate to use

title: Proxy-Host Schema

description: Server name or IP address of the proxy to be used for HTTP/HTTPS communications

title: Proxy-Port Schema

description: Server IP port of the proxy for HTTP/HTTPS communications

$id: #/properties/network/properties/purge

title: Purge Schema

description: Indicates if any currently configured wireless network needs to be removed. Can be useful to avoid profile roaming.

title: Reconfigure Schema

description: If true, will reconfigure any existing and matching network. If false, will leave existing network untouched. Setting used when 'purge' is set to false.

title: Sleep-Policy Schema

description: Wireless sleep policy for Android's Settings.Global parameter (0-WIFI_SLEEP_POLICY_DEFAULT, 1-WIFI_SLEEP_POLICY_NEVER_WHILE_PLUGGED, 2-WIFI_SLEEP_POLICY_NEVER)

title: Frequency-Band Schema

description: Controls the frequency bands supported by the device

default: auto

title: Save-To-File Schema

description: Absolute path to the file where the current network configuration will be saved, empty string indicates network configuration won't be serialized to a file

title: Ephemeral Schema

description: If true, wireless connection profile will be used during staging process, then deleted after staging. If false, wireless connection profile will still be present after staging process.

title: Wait-For-Connection Schema

description: Indicates whether a valid Wi-Fi connection has to be waited once the network configuration is complete. Can be useful when device needs to be configured but a valid Wi-Fi connection is not ready yet.

$id: #/properties/deployment

title: Deployment Schema

description: Section can be used to download a ZIP archive from a server and inflate it to the 'target-path' folder

enum: http https

title: Scheme Schema

description: Deployment download scheme to use

default: http

$id: #/properties/deployment/properties/host

title: Host Schema

description: Host-name or internet-protocol address of the server from which the resource is to be fetched

$id: #/properties/deployment/properties/port

title: Port Schema

description: TCP/IP port to be used to contact the server

$id: #/properties/deployment/properties/path

title: Path Schema

description: Path to the server resource to download, complete with query string if needed

title: Fetch-Timeout Schema

description: The timeout value used when fetching resource from host

title: Check-Timeout Schema

description: The timeout value used when attempting to reach the host server

title: Working-Archive Schema

description: String representation of the archive path-file name, once downloaded

title: Skip-Inflation Schema

description: Instructs the application not to inflate the deployment archive once downloaded, can be useful to speed the OTA update process up

$id: #/properties/blobs

title: Blobs Schema

description: Section used to transfer binary data to newly created file on device

$id: #/properties/blobs/items

title: Items Schema

required: file content

title: File Schema

description: Path to the file to be created. Can be either absolute or relative to the global/target-path parameter value. During file de-serialization, any required (parent) path is automatically created.

title: Content Schema

description: Base64 representation of the actual file content

title: Android-Scan2Deploy Schema


vs-nesting.json

$ref: #/definitions/fileExtension

$ref: #/definitions/fileName

description: If this exist, files with an additional extension should nest under file without additional extension. Example: file.html.css nest under file.html

description: If this exists, files with "extra" extension part in the file name should nest under files without it, but having same name and last extension. Example: file.min.js nest under file.js.

description: Add nesting rules in the order to be applied by corresponding provider, where each rule entry has a form 'child: collection of potential parents'.

description: Remove specified nesting rules if they are merged from higher level nesting settings.

description: Nest files with specific extensions under other specific extensions

$ref: #/definitions/ext-ext

description: Nest specific file names under other specific file names

$ref: #/definitions/file-file

description: Nest files with specified suffixes under files with specified extensions.

$ref: #/definitions/file-ext

description: A greedy version of 'extensionToExtension' and has * as the only child key

description: Determines if this is the root nesting config file and no further inheritance is required.

description: Contains a collection of nesting rule providers specified in the order to be applied.

$ref: #/definitions/providers

title: JSON schema for Visual Studio's file nesting feature


minecraft-biome.json

description:
Spawner options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: swawner options

description:
A spawner for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A mob namespaced entity for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A mod spawn factor for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A minimum mob spawn in a pack for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A maximum mob spawn in a pack for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description: Configuration file defining a biome for a data pack for Minecraft

description:
Used for terrain noise generation. Biomes with positive depth are considered land, biomes with negative depth are oceans
https://minecraft.fandom.com/wiki/Custom_biome

type: number

description:
Used for terrain noise generation. Vertically stretches the terrain. Lower values produce flatter terrain
https://minecraft.fandom.com/wiki/Custom_biome

description: Controls if the current biome has precipitation

enum: none taiga extreme_hills jungle mesa plains savanna icy the_end beach forest ocean desert river swamp mushroom nether

description:
A temperature for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A temperature modifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass and foliage color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Spawns passive mobs as long as random value is less than this
https://minecraft.fandom.com/wiki/Custom_biome

title: effect options

description:
Effect options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A fog color
https://minecraft.fandom.com/wiki/Custom_biome

description:
Decimal value converted from Hex color to use for tree leaves and vines. If not present, the value depends on humidity and temperature
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass color
https://minecraft.fandom.com/wiki/Custom_biome

description:
A sky color
https://minecraft.fandom.com/wiki/Custom_biome

description:
A water color
https://minecraft.fandom.com/wiki/Custom_biome

description:
Decimal value converted from Hex color to use for fog
https://minecraft.fandom.com/wiki/Custom_biome

description:
A grass color modifier
https://minecraft.fandom.com/wiki/Custom_biome

title: particle options

description:
Particle options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle spawning frequency for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: particle options

description:
A particle type for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle state for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Particle properties for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: item

description:
A particle namespaced identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle amount for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle NBT data for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: dust

description:
A dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A dust color component for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A paricle size for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A start dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
An end dust color for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A particle angle in radians for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: vibration

description:
A namespaced identifier of the position source type for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
An offset from entity's feet for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: block

description:
A block position for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A position component for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: entity

description:
A particle move duration for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

const: shriek

description:
A particle delay in ticks for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Sound event to use for ambient sound
https://minecraft.fandom.com/wiki/Custom_biome

title: Mood Sound

description:
Settings for mood sound
https://minecraft.fandom.com/wiki/Custom_biome

description:
Sound event to use
https://minecraft.fandom.com/wiki/Custom_biome

description:
Determines the cubic range of possible positions to play the mood sound. The player is at the center of the cubic range, and the edge length is 2 * block_search_extent + 1
https://minecraft.fandom.com/wiki/Custom_biome

title: Additions Sound

description:
Settings for additions sound
https://minecraft.fandom.com/wiki/Custom_biome

title: Tick Chance

title: Music

description:
Specific music that should be played in the biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Whether or not to replace music which is already playing
https://minecraft.fandom.com/wiki/Custom_biome

description:
The namespaced id of the configured surface builder to use
https://minecraft.fandom.com/wiki/Custom_biome

title: carvers

description:
Carvers to use for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Carvers used during air generation step for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A namespaced id of a configured carver for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Carvers used during liquid generation step for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
Features for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A feature for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A creature spawn probability for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
The structures to generate in this biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
The namespaced ID of a configured structure feature
https://minecraft.fandom.com/wiki/Custom_biome

title: spawners

description:
Entity spawning options for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: spawn costs

description:
Entity identifiers for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: entity identifier

description:
A namespaced entity identifier for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A new mob maximum potential for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

description:
A new mob charge for the current biome
https://minecraft.fandom.com/wiki/Custom_biome

title: Minecraft Data Pack Biome