Remove dap_full_clone feature flag

What does this MR do and why?

Removes the dap_full_clone feature flag now that it has been rolled out to 100% and is default-on.

The flag controlled whether Duo Workflow workloads use a full blobless clone (GIT_DEPTH=0) instead of a shallow clone. Since it is now always enabled, the flag check is removed and the full-clone behavior is inlined unconditionally in StartWorkflowService.

Changes:

  • Delete ee/config/feature_flags/development/dap_full_clone.yml
  • Remove full_clone? and inline the always-true behavior in git_clone_variables and workspace_fixup_commands
  • Remove the legacy shallow-clone path, which was only reachable when dap_full_clone was disabled
  • Drop spec coverage for the disabled path; keep and simplify the enabled-path specs

Why a second feature flag is removed here

This MR also deletes ee/config/feature_flags/gitlab_com_derisk/dap_git_tree_zero_option.yml, which is owned by group::agent foundations.

Removing dap_full_clone made the legacy shallow-clone branch unreachable, and that branch held the only code reference to dap_git_tree_zero_option. An orphaned flag definition fails the rspec:feature-flags job, so the definition has to go in the same MR:

These feature flags appear to be UNUSED
- dap_git_tree_zero_option
Feature flag usage check failed.

The --filter=tree:0 option was never rolled out. Its rollout issue has none of its 38 steps completed, it is a gitlab_com_derisk flag well past that type's documented two-month lifespan (introduced in 18.11), and the code path it guarded has been unreachable on GitLab.com since dap_full_clone reached 100%. So nothing live is lost.

/cc @igor.drozdov — flagging since dap_git_tree_zero_option is yours. If the tree:0 experiment is still wanted, it needs rebuilding on top of the full clone rather than kept alive here.

Update: I aligned with Igor that we can savely remove dap_git_tree_zero_option

Remaining manual steps after deploy

The now-ignored shallow_clone API parameter is removed separately in !250447 (merged).

References

How to set up and validate locally

  • Checkout this branch and restart your gdk

  • Trigger a duo developer flow or another foundational- or custom flow

  • The flow should execute without any issues (and you should see the full clone happening in the job logs)

    image.png

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.

Edited by Thomas Schmidt

Merge request reports

Loading
Loading