Makes it so that a link to the logs for every test that ran is present
in the sidebar of the Evergreen UI. Multiple entries will appear for
the same test file when --repeat is used.
This also fixes an issue where the number of tests skipped would be
incorrect if the same test file was included multiple times in the
"roots" key.
Exposes a way to specify how jstests passed in on the command line
should be run. Defaults to starting a standalone mongod.
--executor=core_small_oplog_rs
is equivalent to smoke.py's --small-oplog-rs
--executor=no_server
is equivalent to smoke.py's --dont-start-mongod
A ServerFailure exception is always converted into a StopExecution
exception, whereas a TestFailure exception is only converted if
--continueOnFailure wasn't specified.
On Windows, this will cause MCI to assign processes to a job object.
Change resmoke.py to only create a job object if the current process
is not already assigned to one.
WiredTiger is used as the default storage engine if the dbpath does
not contain any data files. Otherwise, the storage engine specified
in the storage.bson metadata file is used when the --storageEngine
flag is omitted from the command line invocation.
WiredTiger is used as the default storage engine if the dbpath does
not contain any data files. Otherwise, the storage engine specified
in the storage.bson metadata file is used when the --storageEngine
flag is omitted from the command line invocation.
Change resmoke.py to wait up to 5 minutes for a mongod/mongos process
to start accepting connections. Waiting only 30 seconds for a
connection to be established is insufficient on some build variants in
Evergreen. This is likely due to file preallocation, disk speed, and
other resource factors.
Split out the passthrough tests into separate suites. The MongoDB
deployment is started up by resmoke.py so that we can record the
success/failure of each individual test in MCI.
Added support for parallel execution of tests by dispatching to
multiple MongoDB deployments.
Added support for grouping different kinds of tests (e.g. C++ unit
tests, dbtests, and jstests) so that they can be run together. This
allows for customizability in specifying what tests to execute when
changes are made to a particular part of the code.
