[PATCH 09/23] kconfig: remove CONFIG_KERNEL_CI infrastructure

[Luis Chamberlain <mcgrof@kernel.org>]

Remove the CONFIG_KERNEL_CI Kconfig infrastructure now that all
workflows have been converted to use their own internal loop
configurations or SOAK_DURATION:

- Remove Kconfig.kernel-ci file with all kernel-ci options
- Remove kernel-ci menu and source from Kconfig.kdevops
- Remove CONFIG_KERNEL_CI from kernel-testing defconfig
- Update fstests documentation to mention SOAK_DURATION instead

This completes the removal of the confusing CONFIG_KERNEL_CI feature
that was originally added for loop testing but has been superseded
by better architectural choices.

Generated-by: Claude AI
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
 defconfigs/kernel-testing  |   1 -
 docs/fstests.md            |  13 +--
 kconfigs/Kconfig.kdevops   |   3 -
 kconfigs/Kconfig.kernel-ci | 170 -------------------------------------
 4 files changed, 4 insertions(+), 183 deletions(-)
 delete mode 100644 kconfigs/Kconfig.kernel-ci

diff --git a/defconfigs/kernel-testing b/defconfigs/kernel-testing
index 833d1c5f..3147c0fa 100644
--- a/defconfigs/kernel-testing
+++ b/defconfigs/kernel-testing
@@ -2,5 +2,4 @@ CONFIG_KDEVOPS_TRY_REFRESH_REPOS=y
 CONFIG_KDEVOPS_TRY_UPDATE_SYSTEMS=y
 CONFIG_KDEVOPS_TRY_INSTALL_KDEV_TOOLS=y
 CONFIG_GIT_ALTERNATIVES=y
-CONFIG_KERNEL_CI=y
 CONFIG_WORKFLOW_KOTD_ENABLE=y
diff --git a/docs/fstests.md b/docs/fstests.md
index 3911004c..bc4a2d59 100644
--- a/docs/fstests.md
+++ b/docs/fstests.md
@@ -137,15 +137,10 @@ of a baseline by running fstests in a loop 100 times.  If no new failures have
 been found we consider that we have a high confidence in a baseline and then
 it can be used to verify if new development changes are not causing a regression.
 
-The amount of loops you choose to test with fstests is configurable
-with `CONFIG_KERNEL_CI_STEADY_STATE_GOAL`. We default to 100. This value
-is chosen for a few reasons:
-
-  * Running fstests 100 times takes about 1 week
-  * This is a sensible litmus test to ensure no regressions are
-    introduced with a new delta of patches, if you want to build confidence
-    in some possibly intrusive changes to Linux, or backport some patches
-    without regressing the kernel.
+The preferred method for long-term testing with fstests is to use the
+SOAK_DURATION feature, which allows specific tests designed for soak
+testing to run for extended periods. This provides a more targeted approach
+to stress testing compared to simply running all tests in a loop.
 
 The value originally comes from kdevops use at SUSE Linux enterprise
 distributions, as a litmus test to validate kernel releases, so to ensure
diff --git a/kconfigs/Kconfig.kdevops b/kconfigs/Kconfig.kdevops
index 70d4ec5d..c2362adf 100644
--- a/kconfigs/Kconfig.kdevops
+++ b/kconfigs/Kconfig.kdevops
@@ -187,9 +187,6 @@ menu "Ansible post-bring up provisioning configuration"
 source "kconfigs/Kconfig.ansible_provisioning"
 endmenu
 
-menu "Kernel continous integration configuration"
-source "kconfigs/Kconfig.kernel-ci"
-endmenu
 
 menu "Ansible Configuration"
 source "kconfigs/Kconfig.ansible_cfg"
diff --git a/kconfigs/Kconfig.kernel-ci b/kconfigs/Kconfig.kernel-ci
deleted file mode 100644
index 0ef71fc6..00000000
--- a/kconfigs/Kconfig.kernel-ci
+++ /dev/null
@@ -1,170 +0,0 @@
-config HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	bool
-	default n
-
-if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-
-config KERNEL_CI_DEFAULT_STEADY_STATE_GOAL
-	int
-	default 1
-
-endif
-
-config KERNEL_CI
-	bool "Enable kernel continous integration"
-	default y
-	help
-	  Each subsystem may have its own way to run a test for a longer
-	  period of time. Such is the case for fstests, for fstests this is
-	  the soak duration. Only a few tests leverage soak duration, that is
-	  a test must be designed to leverage soak duration to use it.
-
-	  For subsystems which don't have the same concept or in case you want
-	  to run a a full set of configured tests over and over again, you can
-	  enable the this mechanism.
-
-	  This is enabled by default so to leverage of optional subsystem
-	  specific watchdogs, which may reset a system in case of a crash. The
-	  default number of loops is just 1 so to account for this sensible
-	  default.
-
-	  Workflows support kdevops kernel-ci by implementing a Makefile target
-	  for a test with a "loop" postfix. For instance, to run the fstests
-	  kernel-ci loop you would just run:
-
-	    make fstests-baseline-loop
-
-	  Enable this option if you want to enable and configure certain
-	  kernel-ci features.
-
-if KERNEL_CI
-
-config KERNEL_CI_ENABLE_STEADY_STATE
-	bool "Bound kernel-ci tests with a steady-state goal"
-	default y
-	help
-	  Enable this so that tests don't run forever in a loop if no issues
-	  are found, instead, the kernel-ci loop will bail once a certain number
-	  of full loops have passed without failures. We refer to this goal as
-	  a kernel-ci steady-state test goal. Although the goal can be workflow
-	  specific, for now we define a generic goal which can be used by all
-	  workflows.
-
-	  If you don't enable this, and the test you are running won't ever run
-	  into a failure, you'll have the test run forever.
-
-if KERNEL_CI_ENABLE_STEADY_STATE
-
-config KERNEL_CI_STEADY_STATE_GOAL
-	int "Generic kernel-ci steady-state goal"
-	default 1 if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	default KERNEL_CI_DEFAULT_STEADY_STATE_GOAL if HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	help
-	  The maximum number of possitive successes to have before bailing out
-	  a kernel-ci loop and report success. This value is currently used for
-	  all workflows. A value of 100 means 100 tests will run before we
-	  bail out and report we have achieved steady state for the workflow
-	  being tested.
-
-config KERNEL_CI_STEADY_STATE_INCREMENTAL
-	bool "Bound kernel-ci tests with an incremental steady-state goal"
-	default y
-	help
-	  Enable this so that kernel-ci loop will bail once a certain number
-	  of full loops have passed without resetting the counter on failures.
-	  In this mode, when a test run has failures, the failed tests will be
-	  added to the local expunge lists and success counter will not be
-	  incremented, but the next time that loop will be run it will resume
-	  from the last success counter and stop when it reaches the kernel-ci
-	  steady-state test goal.
-
-endif # KERNEL_CI_ENABLE_STEADY_STATE
-
-config KERNEL_CI_EMAIL_REPORT
-	bool "Enable sending a report on failure"
-	default n if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	default KERNEL_CI_DEFAULT_ENABLE_EMAIL_REPORT if HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	help
-	  Enable this so that a report will be emailed in case of a failure.
-
-if KERNEL_CI_EMAIL_REPORT
-
-config KERNEL_CI_ADD_CUSTOM_SUBJECT_TOPIC
-	bool "Enable a custom kernel-ci subject topic for email reports"
-	default y if BOOTLINUX
-	help
-	  Enable this so that you can customize the subject slightly for
-	  kernel-ci email reports. The email subject prefix will always
-	  start with "kernel-ci: ", if this is enabled we allow you to
-	  slightly configure this. Otherwise the standard "kernel-ci: "
-	  subject prefix will be used.
-
-	  You want to enable this if you are using kernel-ci for different
-	  things, such as testing a distribution kernel but also a stable
-	  or linux-next kernel, so that you can distinguish for which kernel
-	  the report is for.
-
-if KERNEL_CI_ADD_CUSTOM_SUBJECT_TOPIC
-
-config KERNEL_CI_SUBJECT_TOPIC
-	string "Main email subject topic prefix to use"
-	default "" if !BOOTLINUX
-	default BOOTLINUX_TREE_NAME if BOOTLINUX
-	help
-	  Email kernel-ci subject will include the git tree name you are using.
-	  This is set in the BOOTLINUX_TREE_NAME kconfig variable. For instance,
-	  if you decided to build and boot into a linux stable tree the
-	  subject for the kernel-ci email will start with:
-
-	    kernel-ci linux-stable:
-
-config KERNEL_CI_ADD_CUSTOM_SUBJECT_TOPIC_TAG
-	bool "Add git tag to kernel-ci subject topic"
-	default y if BOOTLINUX
-	depends on BOOTLINUX
-	help
-	  Enable this so that the kernel-ci subject topic will also have
-	  the git tag used. For intance, if you have enabled to build and
-	  boot  into linux-next tag next-20210126, and you also enabled this
-	  option, the KERNEL_CI_SUBJECT_TOPIC will be set to "linux-next" and
-	  the subject for the kernel-ci email will start with:
-
-	    kernel-ci linux-next next-20210126:
-
-	  If you do not enable this, then the subject for the kernel-ci email
-	  will start only with:
-
-	    kernel-ci linux-next:
-
-endif # KERNEL_CI_ADD_CUSTOM_SUBJECT_TOPIC
-
-config KERNEL_CI_EMAIL_MODIFY_FROM
-	bool "Modify default from address"
-	select KDEVOPS_SSH_CONFIG_UPDATE_STRICT
-	default n if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	default KERNEL_CI_DEFAULT_EMAIL_MODIFY_FROM if HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	help
-	  If you would like to modify the default from address used to send
-	  the report enable this.
-
-config KERNEL_CI_EMAIL_FROM
-	string "Who to send the email from"
-	depends on KERNEL_CI_EMAIL_MODIFY_FROM
-	default $(shell, echo $USER) if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	default KERNEL_CI_DEFAULT_EMAIL_FROM if HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	  help
-	  The email to pass on to mailx -S from="" setting. This will be used
-	  to modify the from address of the email report sent.
-
-config KERNEL_CI_EMAIL_RCPT
-	string "Who to send email report to"
-	default $(shell, echo $USER) if !HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	default KERNEL_CI_DEFAULT_EMAIL_RCPT if HAVE_KERNEL_CI_CUSTOM_DEFAULTS
-	  help
-	  Comma separated list of users to send the kernel-ci loop email
-	  report to. These are the recipients of the kernel-ci test loop
-	  report.
-
-endif # KERNEL_CI_EMAIL_REPORT
-
-endif # KERNEL_CI
-- 
2.47.2