@alejandro yes, this seems like it's safe to delete. There's some merge conflicts though, probably with your other cleanup MR that was merged

What does this merge request do and why?

See motivation at #1429 (comment 3151889909)

Closes #294

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.

@alejandro this makes sense to me 👍

See motivation at gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#1429 (comment 3151889909)

Allen Cook (5fb7c6c6) at 17 Mar 17:41

Allen Cook (ad719e93) at 17 Mar 17:41

... and 1 more commit

What does this merge request do and why?

Remove unused suggestions code.

How to set up and validate locally

No functional changes.

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.

@alejandro this LGTM, thanks for cleaning this up 🚀

What does this merge request do and why?

Remove unused suggestions code.

How to set up and validate locally

No functional changes.

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.

@alejandro We still have Amazon Q code suggestions that aren't going through the prompt registry, though I don't know how many people are actually using that.

I think we would also need to rework our dashboards / charts to handle the new source of data, this might cause some loss of historical data.

Allen Cook (e4f1c609) at 13 Mar 20:34

Allen Cook (901d34af) at 13 Mar 20:30

Allen Cook (0e946e4b) at 13 Mar 20:00

... and 1 more commit

Allen Cook (6cab8c9e) at 13 Mar 20:00

What does this MR do and why?

This MR removes the dependency_scanning_sbom_scan_result_cache feature flag after successful production rollout and validation.

The feature enables the Dependency Scanning analyzer to check if an SBOM has been previously processed before uploading and triggering a new resource-intensive scan, significantly reducing computational resources and scan times.

Rollout validation

The feature has been successfully rolled out and validated through:

Stage 2a: gitlab-org group enablement with 24-48 hour monitoring
Stage 2b: Global incremental rollout (25% → 50% → 75% → 100%)
Observation: 2+ days at 100% enablement

Success criteria met

• ✅ Cache hit rate > 50% for projects with repeated pipelines
• ✅ No increase in error rates or timeouts
• ✅ Reduction in SBOM scan processing queue size
• ✅ Reduction in average scan completion time
• ✅ No unexpected table growth
• ✅ No stale vulnerability results served

Changes

• Delete feature flag YAML definition
• Remove check_sbom_scan_caching_feature_flag! and sbom_scan_caching_enabled? helper methods
• Remove conditional logic for sbom_digest parameter (now always used)
• Remove feature flag tests from spec file

Related issues

Closes #562694
Related to #590759

@uchandran correct, looks good to me 👍

What does this MR do?

Updates the Code Review Flow docs to note that automatic reviews for groups are enabled by default for new free trials starting in 18.10.

Related issues

#592822

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Allen Cook (2b344ec3) at 13 Mar 19:38

This is expected because CDot doesn't really work on GDK (that I can tell). I've updated the reproduction steps with what I had to do

Allen Cook (f67a247a) at 13 Mar 19:08