Merge Request Approval Policy Time Window

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Background

In the context of Merge Request Approval Policies, specifically for security vulnerability comparisons, there's a need to improve the flexibility and efficiency of the approval process. Currently, the system compares results against the latest pipeline, which can lead to delays if the baseline run is stuck or taking too long.

Problem Statement

The current implementation can significantly prolong the time to merge when the baseline run is delayed or stuck. This affects the development workflow and can cause unnecessary waiting times for merge requests that don't introduce new vulnerabilities.

Proposed Solution

Implement a time window configuration in the Merge Request Approval Policy that allows users to specify a time frame for comparing security results. This will enable comparisons against the latest pipeline with security reports created within a specified time range, rather than always waiting for the most recent baseline run to complete.

Implementation Details

1. Add a new optional configuration option to the policy_tuning section of the Merge Request Approval Policy.
2. The new configuration should allow users to specify a time window (in minutes or hours) for considering security reports.
3. When evaluating the policy, the system should compare the current merge request's security results against the latest pipeline with security reports created within the specified time window.
4. If no security reports are found within the specified time window, fall back to require approval.

Example Configuration:

policy_tuning:
  security_report_time_window: 120 # Time in minutes

Acceptance Criteria

1. Users can configure a time window in the Merge Request Approval Policy.
2. The system correctly identifies and uses security reports within the specified time window for comparisons.
3. The approval process considers the time window when evaluating security vulnerabilities.
4. Proper error handling and fallback mechanisms are in place if no reports are found within the time window.
5. Documentation is updated to reflect this new configuration option.

Additional Considerations

• Ensure backward compatibility with existing policies.
• Provide clear user documentation on how to use and configure this new option.
• Consider adding UI elements in the GitLab interface to make this configuration easily accessible.