[FF] `duo_convert_ci_use_developer_flow` — Switch Convert to GitLab CI button to developer/v1 flow

Summary

This issue is to roll out the feature on production, that is currently behind the duo_convert_ci_use_developer_flow feature flag.

When enabled, the "Convert to GitLab CI/CD" button on Jenkinsfile blob views routes to the actively-maintained developer/v1 foundational flow with an explicit conversion-goal prompt (read Jenkinsfile + dependencies, generate .gitlab-ci.yml, validate via glab ci lint, open MR titled "Convert Jenkins CI to GitLab CI"). When disabled, the legacy convert_to_gl_ci/v1 flow is unchanged.

Introduced in !235418 (merged).

Owners

  • Most appropriate Slack channel to reach out to: #g_agent_foundations
  • Best individual to reach out to: @afontaine

Expectations

What are we expecting to happen?

For projects with duo_remote_flows_enabled = true and duo_features_enabled = true, clicking the "Convert to GitLab CI/CD" button on a Jenkinsfile should produce a developer/v1 workflow (with the structured conversion prompt) instead of a convert_to_gl_ci/v1 workflow. The flagship Duo Developer flow is better maintained than the legacy convert_to_gl_ci flow, has access to richer tooling (including glab ci lint for validation once #593202 (closed) lands), and produces higher-quality conversions.

User-facing visual diff: none. The change is in the click payload, not the rendered UI.

What can go wrong and how would we detect it?

Risk Detection Mitigation
developer/v1 system prompts not yet competent for Jenkins-to-GitLab CI conversion (different from MR conflict resolution, which is the pattern in !230512 (merged)) User reports of low-quality .gitlab-ci.yml output; spike in re-runs of the same Convert action; user feedback on the resulting MRs Roll back the FF; coordinate prompt tuning with the AI Gateway team
Existing Tableau dashboard slice for "Convert to Gitlab CI/CD" goes blind once workflow_definition flips to developer/v1 (the slice currently filters duo_workflow_workload_completed.workflow_definition for convert_to_gl_ci/v1) Slice volume drops to zero while feature usage continues Verify the slice population path during the staging rollout; ship a follow-up MR adding a dedicated click_convert_to_gitlab_ci_button internal event BEFORE the global rollout step (see Telemetry preflight below)
Increased load on the Duo Developer flow (these requests didn't exist on developer/v1 before) duo_workflow_workload_completed event volume for developer/v1 rises while convert_to_gl_ci/v1 falls Capacity is shared with the broader Duo Developer rollout and not currently a concern; revisit if the conversion feature suddenly spikes
Project setting duo_remote_flows_enabled cache staleness causing the button to disappear or appear inappropriately for a window after rollout Cache TTL is short; should self-heal Standard cache-bust on the affected project if reported

Relevant dashboards:

  • Agentic AI Product Adoption (Tableau) — slice "Convert to Gitlab CI/CD"
  • dashboards.gitlab.net Duo Workflow / Duo Agent Platform error-rate panels

Telemetry preflight

Before the Global rollout on production step below, complete the following:

  • Verify how the existing Agentic AI Product Adoption Tableau slice for "Convert to Gitlab CI/CD" is populated. Confirm whether it filters duo_workflow_workload_completed.workflow_definition (most likely) or a different event.
  • If the slice will go blind once the value flips to developer/v1, open and merge a follow-up MR that adds a dedicated click_convert_to_gitlab_ci_button internal event from ee/app/assets/javascripts/blob/components/blob_header.vue. The event should carry property: blob.fileType (so the future MR 2 can widen it to all supported CI platforms for free) and label: workflow_definition. Pattern: mirror ee/app/assets/javascripts/ai/shared/widgets/duo_chat_quick_action.vue:85.
  • Coordinate the Tableau slice update with @dhershkovitch.

Rollout Steps

Note: Please make sure to run the chatops commands in the Slack channel that gets impacted by the command.

Rollout on non-production environments

  • Verify the MR with the feature flag is merged to master and has been deployed to non-production environments with /chatops gitlab run auto_deploy status <merge-commit-of-!235418>
  • Deploy the feature flag at a percentage (recommended percentage: 50%) with /chatops gitlab run feature set duo_convert_ci_use_developer_flow 50 --actors --dev --pre --staging --staging-ref
  • Monitor that the error rates did not increase.
  • Enable the feature globally on non-production environments with /chatops gitlab run feature set duo_convert_ci_use_developer_flow true --dev --pre --staging --staging-ref
  • Verify that the feature works as expected against staging-canary. Steps:
    1. Sign in to staging-canary with an account that has Duo Agent Platform access.
    2. Open a project that has duo_remote_flows_enabled and duo_features_enabled set, and a Jenkinsfile on the default branch.
    3. View the Jenkinsfile in the repo browser.
    4. Click Convert to GitLab CI/CD.
    5. Confirm in the resulting workflow session that workflow_definition is developer/v1 and the agent is following the 4-step conversion prompt (reads dependencies, generates .gitlab-ci.yml, runs glab ci lint, opens an MR titled "Convert Jenkins CI to GitLab CI").
  • If the feature flag causes end-to-end tests to fail, disable the feature flag on staging to avoid blocking deployments.

Before production rollout

  • Complete the Telemetry preflight above. The Tableau slice update (or replacement event) must be in place before the global rollout step, otherwise dashboard visibility into this feature regresses during the very window when we want to monitor it most.

Specific rollout on production

For visibility, all /chatops commands that target production must be executed in the #production Slack channel and cross-posted (with command results) to the responsible team's Slack channel.

  • Ensure that the feature MR has been deployed to both production and canary with /chatops gitlab run auto_deploy status <merge-commit-of-!235418>
  • This is a project-actor flag. Enable for internal dogfooding projects first:
    • /chatops gitlab run feature set --project=gitlab-org/gitlab,gitlab-com/www-gitlab-com duo_convert_ci_use_developer_flow true
  • Verify that the feature works for the specific actors (sign in, click Convert on a Jenkinsfile, confirm developer/v1 payload).
  • Optionally enable for the gitlab_team_members feature-group to widen dogfooding:
    • /chatops gitlab run feature set --feature-group=gitlab_team_members duo_convert_ci_use_developer_flow true

Preparation before global rollout

  • Set a milestone to this rollout issue.
  • Verify the change doesn't need a change management issue. (Probably no — this is a Duo Agent Platform feature, not a core platform change.)
  • Be available for at least 2 hours after global rollout for monitoring.
  • Confirm the existing user docs for "Convert to GitLab CI/CD" are still accurate (the user-facing button and outcome are unchanged; only the underlying flow string changed). If documentation references the legacy convert_to_gl_ci flow by name, update.
  • Notify the #support_gitlab-com Slack channel and #g_agent_foundations.

Global rollout on production

For visibility, all /chatops commands that target production must be executed in the #production Slack channel and cross-posted to #g_agent_foundations.

  • Incrementally roll out the feature on production. Examples:
    • /chatops gitlab run feature set duo_convert_ci_use_developer_flow 25 --actors
    • /chatops gitlab run feature set duo_convert_ci_use_developer_flow 50 --actors
    • /chatops gitlab run feature set duo_convert_ci_use_developer_flow 100 --actors
    • Between every step wait for at least 15 minutes and monitor dashboards.gitlab.net Duo Agent Platform error rates and the (updated) Tableau slice.
  • After the feature has been 100% enabled, wait for at least one day before releasing the feature.

Release the feature

After the feature has been deemed stable (~1–2 milestones of stable usage at 100%):

  • Create a cleanup MR that:
    • Removes all references to duo_convert_ci_use_developer_flow from the codebase.
    • Removes the YAML at config/feature_flags/gitlab_com_derisk/duo_convert_ci_use_developer_flow.yml.
    • Simplifies ee/app/assets/javascripts/blob/components/blob_header.vue so duoWorkflowDefinition and duoWorkflowGoal no longer branch (both always use the developer/v1 path).
    • Updates ee/spec/frontend/blob/components/blob_header_spec.js to drop the FF-off case.
    • Optionally marks the convert_to_gl_ci/v1 foundational flow as feature_maturity: "deprecated" in ee/app/models/ai/catalog/foundational_flow.rb (but does NOT delete it — in-flight workflows and AI Catalog item-consumer rows still point at it).
  • Once the cleanup MR is deployed, delete the flag from all environments: /chatops gitlab run feature delete duo_convert_ci_use_developer_flow --dev --pre --staging --staging-ref --production
  • Close the feature issue (only if MR 2 — file-type expansion — has also shipped; otherwise leave open for that work).
  • Close this rollout issue.

Rollback Steps

  • Disable the feature on production: /chatops gitlab run feature set duo_convert_ci_use_developer_flow false
  • Disable on non-production: /chatops gitlab run feature set duo_convert_ci_use_developer_flow false --dev --pre --staging --staging-ref
  • Delete entirely from all environments (if the rollout is permanently abandoned): /chatops gitlab run feature delete duo_convert_ci_use_developer_flow --dev --pre --staging --staging-ref --production

After a rollback, the legacy convert_to_gl_ci/v1 flow continues to work unchanged — no data migration or cleanup is needed.