@fabiopitino - Other than the comments from Eduardo, this LGTM. Tested locally and it works 👍

What does this MR do and why?

Add feature flag to control version of Fix Pipeline flow

The feature flag controls whether fix_pipeline_next is used. The "Next" version contains substantial changes to the UX and cost optimizations.

In gitlab-org/modelops/applied-ml/code-suggestions/ai-assist!4756 we are introducing fix_pipeline_next and that MR needs to be merged before we can enable the feature flag.

Related to #589268

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Hey @ssuman3 - Thanks for the MR.

I noticed in your test, the flow decided to add a comment instead of make a fix. The original problem occurred when the flow tried to make a fix on a default branch failure (you can add a simple syntax failure in your CI file in default branch to recreate this). Apologies if that wasnt clear. Under those conditions, the flow still tried to call the tool with bad params at the comment_link step: langsmith.

One more comment: we need to keep v1 and experimental in sync (with experimental being a superset of v1) until they inherit from eachother, so the changes will have to be added to experimental too.

@fabiopitino @eduardobonet That makes sense to me! Thanks for the info

Roman Eisner (b500ad1a) at 16 Mar 21:33

Roman Eisner (e3ce1e0a) at 16 Mar 20:23

Roman Eisner (53f88a28) at 16 Mar 20:23

... and 1 more commit

What does this merge request do and why?

This change modifies a pipeline fixing workflow to handle two scenarios: creating a new merge request for fixes, or pushing fixes directly to an existing merge request.

Previously, the system always created a new merge request when fixing pipeline issues. Now it checks if there's already an associated merge request - if so, it pushes the fixes directly to that existing branch instead of creating a duplicate. The workflow also updates how it handles git operations (fetching and checking out the right branch) and adjusts the commenting system to notify users appropriately based on whether fixes went to a new or existing merge request.

This prevents creating unnecessary duplicate merge requests when fixing pipelines that are already associated with ongoing work, making the process cleaner and more intuitive for developers.

How to set up and validate locally

• create a project with a .gitlab-ci.yml and add bugs in a MR and then on the main branch. See !4756 (comment 3134748978) for test cases.

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.
• If this change requires executor implementation: verified that issues/MRs exist for both Go executor and Node executor or confirmed that changes are backward-compatible and don't break existing executor functionality.

Related to gitlab-org/gitlab#589268

Roman Eisner (94c0314c) at 16 Mar 20:12

Roman Eisner (df23e8cb) at 16 Mar 20:04

Hey @fabiopitino

The start_workflow_service.rb is used by a few different entry points. I think a better approach would be to push the feature flag to the front-end (where the flow is initiated) and pass in a different workflow definition based on the flag. Something similar to what you can see here. Edit: Actually this might be a more complete reference.

You would have to add the conditional to 3 .vue components that specify the workflow-definition though.

Thanks @fabiopitino - LGTM! 🚀

What does this merge request do and why?

This change modifies a pipeline fixing workflow to handle two scenarios: creating a new merge request for fixes, or pushing fixes directly to an existing merge request.

Previously, the system always created a new merge request when fixing pipeline issues. Now it checks if there's already an associated merge request - if so, it pushes the fixes directly to that existing branch instead of creating a duplicate. The workflow also updates how it handles git operations (fetching and checking out the right branch) and adjusts the commenting system to notify users appropriately based on whether fixes went to a new or existing merge request.

This prevents creating unnecessary duplicate merge requests when fixing pipelines that are already associated with ongoing work, making the process cleaner and more intuitive for developers.

How to set up and validate locally

• create a project with a .gitlab-ci.yml and add bugs in a MR and then on the main branch. See !4756 (comment 3134748978) for test cases.

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.
• If this change requires executor implementation: verified that issues/MRs exist for both Go executor and Node executor or confirmed that changes are backward-compatible and don't break existing executor functionality.

Related to gitlab-org/gitlab#589268

Roman Eisner (840520ae) at 16 Mar 19:23

Closing this MR as it's fixed in the other one

What does this merge request do and why?

Fixes can_log_request_data() in the cloud AI Gateway to honour the x-gitlab-enabled-instance-verbose-ai-logs header for SM instances opting in to data sharing.

Previously, the cloud AI Gateway path only checked the expanded_ai_logging feature flag, which is explicitly suppressed for SM instances. The opt-in header sent by SM GitLab instances was ignored.

See gitlab-org/gitlab#587976

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Merge request checklist

• Tests added for new functionality. If not, please raise an issue to follow up.
• Documentation added/updated, if needed.
• If this change requires executor implementation: verified that issues/MRs exist for both Go executor and Node executor or confirmed that changes are backward-compatible and don't break existing executor functionality.

@fabiopitino - I think this is legit

@junminghuang - Thanks for the MR, LGTM! I added one comment for discussion but it's definitely not blocking.

Summary

Adds comprehensive documentation for the conversation compaction feature, which automatically summarizes older conversation history to stay within LLM token limits.

Closes #2036

What does this MR do?

• Creates docs/context_management/compaction.md with:

  • Feature overview explaining what compaction is and why it's needed
  • Supported workflow types table showing integration status
  • Configuration guide for Legacy Chat Workflow and Flow Registry Experimental
  • Configuration parameters reference
  • How compaction works (token estimation, threshold check, summarization)
  • State management explanation for different workflow types
  • Best practices and feature flag information

• Updates docs/flow_registry/experimental.md with:

  • Adds compaction parameter to AgentComponent optional parameters
  • Adds compaction parameter to OneOffComponent optional parameters
  • Adds YAML examples for both components with compaction enabled

How to set up and validate locally

1. Review the documentation files for accuracy and completeness
2. Run make lint-doc to verify documentation linting passes

Related issues and MRs

• Closes #2036
• Parent issue: &42 #1863
• Original compaction implementation: !4629
• Chat workflow integration: !4867