Path: blob/master/tools/testing/ktest/examples/include/bisect.conf
26299 views
#1# This example shows the bisect tests (git bisect and config bisect)2#345# The config that includes this file may define a RUN_TEST6# variable that will tell this config what test to run.7# (what to set the TEST option to).8#9DEFAULTS IF NOT DEFINED RUN_TEST10# Requires that hackbench is in the PATH11RUN_TEST := ${SSH} hackbench 50121314# Set TEST to 'bisect' to do a normal git bisect. You need15# to modify the options below to make it bisect the exact16# commits you are interested in.17#18TEST_START IF ${TEST} == bisect19TEST_TYPE = bisect20# You must set the commit that was considered good (git bisect good)21BISECT_GOOD = v3.322# You must set the commit that was considered bad (git bisect bad)23BISECT_BAD = HEAD24# It's best to specify the branch to checkout before starting the bisect.25CHECKOUT = origin/master26# This can be build, boot, or test. Here we are doing a bisect27# that requires to run a test to know if the bisect was good or bad.28# The test should exit with 0 on good, non-zero for bad. But see29# the BISECT_RET_* options in samples.conf to override this.30BISECT_TYPE = test31TEST = ${RUN_TEST}32# It is usually a good idea to confirm that the GOOD and the BAD33# commits are truly good and bad respectively. Having BISECT_CHECK34# set to 1 will check both that the good commit works and the bad35# commit fails. If you only want to check one or the other,36# set BISECT_CHECK to 'good' or to 'bad'.37BISECT_CHECK = 138#BISECT_CHECK = good39#BISECT_CHECK = bad4041# Usually it's a good idea to specify the exact config you42# want to use throughout the entire bisect. Here we placed43# it in the directory we called ktest.pl from and named it44# 'config-bisect'.45MIN_CONFIG = ${THIS_DIR}/config-bisect46# By default, if we are doing a BISECT_TYPE = test run but the47# build or boot fails, ktest.pl will do a 'git bisect skip'.48# Uncomment the below option to make ktest stop testing on such49# an error.50#BISECT_SKIP = 051# Now if you had BISECT_SKIP = 0 and the test fails, you can52# examine what happened and then do 'git bisect log > /tmp/replay'53# Set BISECT_REPLAY to /tmp/replay and ktest.pl will run the54# 'git bisect replay /tmp/replay' before continuing the bisect test.55#BISECT_REPLAY = /tmp/replay56# If you used BISECT_REPLAY after the bisect test failed, you may57# not want to continue the bisect on that commit that failed.58# By setting BISECT_START to a new commit. ktest.pl will checkout59# that commit after it has performed the 'git bisect replay' but60# before it continues running the bisect test.61#BISECT_START = 2545eb6198e7e1ec50daa0cfc64a4cdfecf24ec96263# Now if you don't trust ktest.pl to make the decisions for you, then64# set BISECT_MANUAL to 1. This will cause ktest.pl not to decide65# if the commit was good or bad. Instead, it will ask you to tell66# it if the current commit was good. In the mean time, you could67# take the result, load it on any machine you want. Run several tests,68# or whatever you feel like. Then, when you are happy, you can tell69# ktest if you think it was good or not and ktest.pl will continue70# the git bisect. You can even change what commit it is currently at.71#BISECT_MANUAL = 1727374# One of the unique tests that ktest does is the config bisect.75# Currently (which hopefully will be fixed soon), the bad config76# must be a superset of the good config. This is because it only77# searches for a config that causes the target to fail. If the78# good config is not a subset of the bad config, or if the target79# fails because of a lack of a config, then it will not find80# the config for you.81TEST_START IF ${TEST} == config-bisect82TEST_TYPE = config_bisect83# set to build, boot, test84CONFIG_BISECT_TYPE = boot85# Set the config that is considered bad.86CONFIG_BISECT = ${THIS_DIR}/config-bad87# This config is optional. By default it uses the88# MIN_CONFIG as the good config.89CONFIG_BISECT_GOOD = ${THIS_DIR}/config-good909192