Improve ref resolution at pipeline creation

What does this MR do and why?

This MR refactors ref resolution logic during pipeline creation to improve consistency and maintainability. Currently, ref type checking is scattered across multiple pipeline chain steps with inconsistent patterns. This change introduces a centralized Gitlab::Git::RefResolver class that handles all ref resolution logic in one place.

Key improvements:

  • Centralized ref resolution: New RefResolver class consolidates logic for determining whether a ref is a branch, tag, merge request ref, or workload ref
  • Consistent ambiguity handling: Moves ambiguous ref detection (when a name exists as both branch and tag) earlier in the pipeline validation chain
  • Clearer validation flow: The Repository validation step now checks for ambiguous refs first, then ref existence, then commit SHA - making the validation order more logical
  • Better separation of concerns: Separates "does this ref exist?" checks from "what type of ref is this?" logic
  • Improved method naming: Changes from *_exists? methods to simpler branch?, tag?, etc. when checking ref types (behind feature flag)

The refactoring is behind the ci_pipeline_ref_resolution feature flag to allow gradual rollout and easy rollback if needed.

References

Rollout of ci_pipeline_ref_resolution feature flag (#590599)

How to set up and validate locally

  1. Create a branch and tag with the same name to test ambiguous ref handling:

    project = Project.find_by_full_path('your-namespace/your-project')
    project.repository.add_branch(User.first, 'test-ref', 'master')
    project.repository.add_tag(User.first, 'test-ref', 'master')
  2. Enable the feature flag:

    Feature.enable(:ci_pipeline_ref_resolution, project)
  3. Try creating a pipeline with the ambiguous ref - it should fail with "Ref is ambiguous"

  4. Test normal pipeline creation with branches and tags continues to work as expected

Feature Flag Rollout

Rollout issue: #590599

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 Avielle Wolfe

Merge request reports

Loading