# Copyright (c) Microsoft Corporation.
# Licensed under the MIT License.

[[profile.default.overrides]]
filter = 'package(~vmm_tests)'
# Mark VMM tests as heavy and requiring more threads due to their memory and CPU
# usage. For local dev runs, you may need to manually restrict the number of
# threads running via the -j cli arg.
threads-required = 2

[[profile.default.overrides]]
# use fuzzy-matching for the package() to allow out-of-tree tests to use the
# same profile
filter = 'package(~vmm_tests) and test(openhcl)'
# Mark OpenHCL VMM tests as extra heavy, as they have to also simulate VTL2.
threads-required = 4

# Profile for CI runs.
[profile.ci]
# Set the default timeout to 1 second, with tests terminated after 5 seconds
slow-timeout = { period = "1s", terminate-after = 5 }
# Print out output for failing tests at the end of the run.
failure-output = "final"
# Do not cancel the test run on the first failure.
fail-fast = false

[profile.ci.junit]
path = "junit.xml"
store-success-output = "true"

[[profile.ci.overrides]]
# allow loom based tests more time, as they take a while
filter = 'test(loom)'
slow-timeout = { period = "30s", terminate-after = 2 }

[[profile.ci.overrides]]
# use fuzzy-matching for the package() to allow out-of-tree tests to use the
# same profile
filter = 'package(~vmm_tests)'
# Allow VMM tests longer timeouts.
# Important Note: Petri's watchdogs need to know this value too.
# If you change it here then change it there!
slow-timeout = { period = "3m", terminate-after = 2 }

# TEMP (hopefully): For reasons that continue to befuddle, running Windows
# release-mode unit tests in flowey CI is resulting in seemingly-random
# tests occationally stalling by up to ~10 seconds.
#
# This did not occur in the "legacy" non-flowey CI, and so the question becomes:
# what subtle different in execution environments between the new pipeline and
# the old pipeline is causing this different behavior?
[[profile.ci.overrides]]
platform = 'cfg(windows)'
slow-timeout = { period = "1s", terminate-after = 30 }
