Redefine Flow
Redefine Flow presents the valid runs that are expected to be executed within Redefine. Each flow is associated with a distinct test suite and contains rules that define what constitutes valid runs in that specific flow.
Why is Redefine Flow configuration required?
Redefine learns from the history of runs over time. It is crucial to ensure that the data from which Redefine learns contains only relevant runs. Customers might install Redefine in a few unexpected places, or there could be changes in the CI over time that affect Redefine's learning process. It is therefore essential that the Redefine model learns only from relevant data to yield the best results.
The flows are differentiated by test suites to provide flow-specific predictions and to allow monitoring of performance by flow in the dashboard.
How to update the flow configuration?
New customers will configure their flows during the onboarding process. Existing customers can view and update their flow configuration on the settings page.
Flow Properties
Each flow is defined by a unique name and includes one or more rules. Each rule represents a specific type of run. In scenarios where multiple rules are employed, one rule may pertain to the optimized run (for example, the optimized pull request run), while another may be associated with the corresponding feedback run (such as the passive discover run).
The properties of each rule within a flow include:
Mode: This property indicates the selection mode employed within the flow. To view the flow's selection mode, use the Redefine installation command:
redefine install --<selection mode>Run Type: This property allows you to determine whether the rule applies to runs that are either pull requests or post-merge commits. Usually, runs optimized by Redefine are pull request runs, while learning runs are based on post-merge commits.
Pipeline: This property designates the pipeline name associated with the valid runs within the flow, ensuring precise run association.
Job: This property defines the job name(s) relevant to the valid runs within the flow. If there are multiple valid job names, a multi-select feature can be used, or you can select "all current and future jobs" for comprehensive inclusion.
Examples
Let's suppose a company has two components: a web app with E2E tests and an API. Here's how its flows would be configured:
If the company uses Redefine in Optimize mode:
Each flow has an optimize rule and a discover rule for post-merge learning (Feedback).
If the company is planning to install in Optimize mode but is still in the learning phase:
Each flow has two rules in discover mode since Redefine is still gathering data in discover mode. At the end of the learning phase, the pull request's selection mode will be switched to Optimize.
If the company uses Redefine in Fail-Fast mode:
In this case, Redefine is configured in Fail-Fast mode and, as such, does not require a feedback phase for installation.
Last updated
