Struct NextestConfig

pub struct NextestConfig { /* private fields */ }

Overall configuration for nextest.

This is the root data structure for nextest configuration. Most runner-specific configuration is managed through profiles, obtained through the profile method.

For more about configuration, see Configuration in the nextest book.

Implementations

impl NextestConfig

pub const CONFIG_PATH: &'static str = ".config/nextest.toml"

The default location of the config within the path: .config/nextest.toml, used to read the config from the given directory.

pub const DEFAULT_CONFIG: &'static str = "# This is the default config used by nextest. It is embedded in the binary at\n# build time. It may be used as a template for .config/nextest.toml.\n\n[store]\n# The directory under the workspace root at which nextest-related files are\n# written. Profile-specific storage is currently written to dir/<profile-name>.\ndir = \"target/nextest\"\n\n# This section defines the default nextest profile. Custom profiles are layered\n# on top of the default profile.\n[profile.default]\n# The set of tests run by `cargo nextest run` by default.\ndefault-filter = \"all()\"\n\n# \"retries\" defines the number of times a test should be retried. If set to a\n# non-zero value, tests that succeed on a subsequent attempt will be marked as\n# flaky. Can be overridden through the `--retries` option.\n# Examples\n# * retries = 3\n# * retries = { backoff = \"fixed\", count = 2, delay = \"1s\" }\n# * retries = { backoff = \"exponential\", count = 10, delay = \"1s\", jitter = true, max-delay = \"10s\" }\nretries = 0\n\n# The number of threads to run tests with. Supported values are either an integer or\n# the string \"num-cpus\". Can be overridden through the `--test-threads` option.\ntest-threads = \"num-cpus\"\n\n# The number of threads required for each test. This is generally used in overrides to\n# mark certain tests as heavier than others. However, it can also be set as a global parameter.\nthreads-required = 1\n\n# Extra arguments to pass in to the test binary at runtime. Intended primarily for\n# communication with custom test harnesses -- use with caution!\nrun-extra-args = []\n\n# Show these test statuses in the output.\n#\n# The possible values this can take are:\n# * none: no output\n# * fail: show failed (including exec-failed) tests\n# * retry: show flaky and retried tests\n# * slow: show slow tests\n# * pass: show passed tests\n# * skip: show skipped tests (most useful for CI)\n# * all: all of the above\n#\n# Each value includes all the values above it; for example, \"slow\" includes\n# failed and retried tests.\n#\n# Can be overridden through the `--status-level` flag.\nstatus-level = \"pass\"\n\n# Similar to status-level, show these test statuses at the end of the run.\nfinal-status-level = \"flaky\"\n\n# \"failure-output\" defines when standard output and standard error for failing tests are produced.\n# Accepted values are\n# * \"immediate\": output failures as soon as they happen\n# * \"final\": output failures at the end of the test run\n# * \"immediate-final\": output failures as soon as they happen and at the end of\n# the test run; combination of \"immediate\" and \"final\"\n# * \"never\": don\'t output failures at all\n#\n# For large test suites and CI it is generally useful to use \"immediate-final\".\n#\n# Can be overridden through the `--failure-output` option.\nfailure-output = \"immediate\"\n\n# \"success-output\" controls production of standard output and standard error on success. This should\n# generally be set to \"never\".\nsuccess-output = \"never\"\n\n# Cancel the test run on the first failure. For CI runs, consider setting this\n# to false.\nfail-fast = true\n\n# Treat a test that takes longer than the configured \'period\' as slow, and print a message.\n# See <https://nexte.st/docs/features/slow-tests> for more information.\n#\n# Optional: specify the parameter \'terminate-after\' with a non-zero integer,\n# which will cause slow tests to be terminated after the specified number of\n# periods have passed.\n# Example: slow-timeout = { period = \"60s\", terminate-after = 2 }\nslow-timeout = { period = \"60s\" }\n\n# Treat a test as leaky if after the process is shut down, standard output and standard error\n# aren\'t closed within this duration.\n#\n# This usually happens in case of a test that creates a child process and lets it inherit those\n# handles, but doesn\'t clean the child process up (especially when it fails).\n#\n# See <https://nexte.st/docs/features/leaky-tests> for more information.\nleak-timeout = \"100ms\"\n\n# `nextest archive` automatically includes any build output required by a standard build.\n# However sometimes extra non-standard files are required.\n# To address this, \"archive.include\" specifies additional paths that will be included in the archive.\narchive.include = [\n # Examples:\n #\n # { path = \"application-data\", relative-to = \"target\" },\n # { path = \"data-from-some-dependency/file.txt\", relative-to = \"target\" },\n #\n # In the above example:\n # * the directory and its contents at \"target/application-data\" will be included recursively in the archive.\n # * the file \"target/data-from-some-dependency/file.txt\" will be included in the archive.\n]\n\n[profile.default.junit]\n# Output a JUnit report into the given file inside \'store.dir/<profile-name>\'.\n# If unspecified, JUnit is not written out.\n\n# path = \"junit.xml\"\n\n# The name of the top-level \"report\" element in JUnit report. If aggregating\n# reports across different test runs, it may be useful to provide separate names\n# for each report.\nreport-name = \"nextest-run\"\n\n# Whether standard output and standard error for passing tests should be stored in the JUnit report.\n# Output is stored in the <system-out> and <system-err> elements of the <testcase> element.\nstore-success-output = false\n\n# Whether standard output and standard error for failing tests should be stored in the JUnit report.\n# Output is stored in the <system-out> and <system-err> elements of the <testcase> element.\n#\n# Note that if a description can be extracted from the output, it is always stored in the\n# <description> element.\nstore-failure-output = true\n\n# This profile is activated if MIRI_SYSROOT is set.\n[profile.default-miri]\n"

Contains the default config as a TOML file.

Repository-specific configuration is layered on top of the default config.

pub const ENVIRONMENT_PREFIX: &'static str = "NEXTEST"

Environment configuration uses this prefix, plus a _.

pub const DEFAULT_PROFILE: &'static str = "default"

The name of the default profile.

pub const DEFAULT_MIRI_PROFILE: &'static str = "default-miri"

The name of the default profile used for miri.

pub const DEFAULT_PROFILES: &'static [&'static str] = _

A list containing the names of the Nextest defined reserved profile names.

pub fn from_sources<'a, I>( workspace_root: impl Into<Utf8PathBuf>, graph: &PackageGraph, config_file: Option<&Utf8Path>, tool_config_files: impl IntoIterator<IntoIter = I>, experimental: &BTreeSet<ConfigExperimental>, ) -> Result<Self, ConfigParseError>

where I: Iterator<Item = &'a ToolConfigFile> + DoubleEndedIterator,

Reads the nextest config from the given file, or if not specified from .config/nextest.toml in the workspace root.

tool_config_files are lower priority than config_file but higher priority than the default config. Files in tool_config_files that come earlier are higher priority than those that come later.

If no config files are specified and this file doesn’t have .config/nextest.toml, uses the default config options.

pub fn profile( &self, name: impl AsRef<str>, ) -> Result<EarlyProfile<'_>, ProfileNotFound>

Returns the profile with the given name, or an error if a profile was specified but not found.

Trait Implementations

impl Clone for NextestConfig

fn clone(&self) -> NextestConfig

Returns a copy of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for NextestConfig

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.