Cycle 2.30.0
Released 2026-09-21.
New features
A new CycleScript runtime, now the default
CycleScript runs on a new execution engine, and it is the default for every installation in this release. Earlier releases used it only where it had been turned on explicitly.
Your existing tests, playlists and group tests run and report the same way. Nothing about how you write or organize a test changes.
If a test behaves differently than it did on 2.29, tell us. That is the most useful thing you can report about this release.
Setting CYCLE_GO_INTERPRETER_ENABLED=false puts an installation back on the previous engine in the meantime.
Data breakpoints when debugging in VS Code
CycleScript debugging supports data breakpoints, which pause a run when the value of a variable changes rather than when execution reaches a line. Debugging is a Cycle Testing VS Code extension behavior, so data breakpoints are set and hit there rather than in the Cycle Desktop IDE. A data breakpoint stops on the step that made the change, and the pause message names the variable and both values.
New Cycle CLI commands
cycle-cli create feature|playlist|grouptest|api|blueprintwrites a new Cycle project file from a built-in template.cycle-cli run api <path.api>runs one saved API request without opening the Cycle Desktop IDE.
Blueprint library location as a project setting
A Cycle project's Blueprint library location is a typed project setting, BlueprintLibraryDir, and can be set from the Settings UI in the Cycle Desktop IDE.
- A project file written before this release is migrated on first read, so the earlier free-form
blueprint.*settings do not need to be edited by hand. - Relative and library-relative blueprint paths resolve from the command line, so
cycle-cli --blueprint <relative path>runs against a project bound to a library. - Blueprint paths resolve the same way under both engines.
Discovery: answering the questionnaire from a configuration export
Discovery can answer its questionnaire from a Blue Yonder WMS configuration export instead of asking a person every question. The config scan joins answering questions and ingesting documents as an input source at the Discovery hub.
- Drop the export into the project's
Config-Exportfolder, one CSV per configuration table. A project that already holds the folder is scanned when Discovery starts. - The scan reports four counts: answered, unresolved, deferred, and skipped. A deferred question was gated behind an answer nobody had given yet, and settles itself once that answer arrives.
- Each scan answer records that the scan supplied it and which configuration it read, so the reasoning can be checked rather than trusted.
- The export is authoritative. The scan replaces answers already entered by hand, and lists each replacement alongside its previous value.
Cycle MCP
- Element map as the source of truth for locators: Web selector lookups read one element map of 675 entries across 29 sections, replacing the separate locator inventory that served them before.
- Menu paths resolve to screens: A menu path resolves to the screen it names, so a selector lookup for that screen returns the screen's own elements rather than whatever shares its wording.
get-contexttool: An agent retrieves a named context fragment withget-context(system, key)instead of browsingcycle://context/*resources. Keys includeprimer,manifest,locators, andinteraction_model.- Interface gates answered by a person: The Blue Yonder discovery map asks a person the questions that no query can answer, and defers the probes that depend on those answers until they are given.
- Saved connections in
run_step:run_stepacceptsproject_pathanduser_profile, so a step executed through Cycle MCP resolves the same saved connections and credentials that a run resolves. db_output_dironrun_test: Passingdb_output_dircopies the results database to that directory and returns acycle://run-errorshint when the run exits with a non-zero code.update-project-settingstool: One tool writes any project setting by name, replacingblueprint_bind-library. A risky path value is written with a warning rather than refused outright.
Changes
- Cycle CLI v2 is the default command surface: The
CYCLE_CLI_VERSION_TWO_ENABLEDfeature flag has been removed and the v2 surface is always active. Existing scripts that use the bare invocation form continue to work. Flags that v2 replaced now warn in the bare form and are rejected with therunverb. cycle-cli auth login --token <value>records the login: Earlier releases authenticated only the process that ran the command, so the next invocation was signed out again.- A run can authenticate from the environment: When no other credential is available, a run falls back to the
CYCLE_CLI_CLIENT_IDandCYCLE_CLI_CLIENT_SECRETpair already present in the environment. The fallback is consulted last, so it cannot change the outcome of a run that already works. - Blue Yonder context is enabled by default: Cycle MCP loads Blue Yonder context for every project as an interim step toward a per-project declaration of the system under test.
- Inspector reporting choices override the project's stored settings: An output left unticked in the Inspector panel is off for that run, where earlier releases fell back to the stored project setting. The Inspector's state is treated as a deliberate choice for the run it starts.
- A desktop run stops before executing when the reporting Data Store cannot be reached: A run started from the Cycle Desktop IDE validates the Data Store first and ends without executing any Feature File when that check fails. Earlier releases began executing and failed later.
- Out-of-order or repeated
Ifblock clauses are reported as an error: A Feature File whoseIfblock clauses appear out of order, or more than once, now reports an error naming the problem.
Removed
- The
blueprint_bind-libraryMCP tool has been replaced byupdate-project-settings. - The
-skip-initial-purgeand-verbose-shutdownCycle CLI flags have been removed.