병합 가능성 프레임워크

최초 작업은 더 명확히 정의된 병합 가능성 프레임워크를 시작했습니다.

원래 병합 가능성 지식은 백엔드와 프론트엔드 전체에 퍼져 있었습니다. 이 작업은 일부 병합 가능성 기준을 백엔드의 동일한 위치로 통합하는 것이었습니다. 이렇게 하면 프론트엔드에서 간단히 API를 사용하고 오류를 표시할 수 있습니다.

새로운 확인 항목 추가

새로운 병합 확인 항목을 추가할 때 몇 가지 선택을 해야 합니다:

  • 이 확인 사항을 건너뛸 수 있는지, 그리고 검사를 통과할 때 병합 기능의 일부인가요?
  • 이 확인 사항을 캐시할 수 있는가요?
    • 그렇다면 적절한 캐시 키는 무엇인가요?
  • 이 확인 사항에는 켜거나 끄는 설정이 있나요?

이러한 질문에 답한 후, 새 확인 항목을 만들 수 있습니다.

병합 가능성 확인은 app/services/merge_requests/mergeability/에 저장됩니다.

  1. 새 확인을 만들려면 다음을 기본으로 사용할 수 있습니다:

    # frozen_string_literal: true
    module MergeRequests
      module Mergeability
        class CheckCiStatusService < CheckBaseService
           identifier :ci_must_pass # 어떤 확인이 실패했는지를 나타내는 식별자
           description 'CI가 통과했는지 확인합니다' # GraphQL을 통해 반환된 확인에 대한 설명
    
          def execute
            # 병합 확인이 설정 뒤에 있다면, 설정이 false이면 비활성 상태를 반환합니다
            return inactive unless merge_request.only_allow_merge_if_pipeline_succeeds?
    
            if merge_request.mergeable_ci_state?
              success
            else
              failure
            end
          end
    
          def skip?
            # 여기서 param을 확인하거나 건너뛸 수 없을 경우 false를 반환합니다
            # MR의 건너뛰기 여부는 검사를 통과할 때 병합 기능과 관련이 있습니다
            params[:skip_ci_check].present?
          end
    
          # 여기서 true를 반환하면 def cache_key 메서드를 만들고
          # 올바르게 무효화될 적절한 캐시 키를 제공해야 합니다.
          def cacheable?
            false
          end
        end
      end
    end
    
  2. def mergeable_state_checks 메서드에 새 확인을 추가합니다.
  3. app/graphql/types/merge_requests/detailed_merge_status_enum.rb에서 GraphQL enum에 새 확인을 추가합니다.
  4. bundle exec rake gitlab:graphql:compile_docs를 사용하여 GraphQL 문서를 업데이트합니다.
  5. doc/api/merge_requests.md에서 API 문서를 업데이트합니다.
  6. 새 메시지를 지원하도록 프론트엔드를 업데이트합니다: app/assets/javascripts/vue_merge_request_widget/components/checks/message.vue.

고려 사항

  1. 건너뛰는 것이 좋은가요? 검사가 병합 기능 검사 작업의 일부인 경우 건너뛸 수 있는 확인을 추가해야 합니다. 그렇지 않으면 false를 반환해야 합니다.
  2. 성능: 이 병합 가능성 확인은 매우 자주 실행되므로, 성능이 큰 고려사항입니다. 새 병합 가능성 확인을 어떻게 수행하는지 확인하는 것이 중요합니다. 일반적으로 10-20ms가 예상됩니다.
  3. 캐싱도 옵션입니다. def cacheable? 메서드를 true로 설정할 수 있으며, 그 경우 해당 확인에 대한 캐시 키를 설정하는 또 다른 메서드 def cache_key를 만들어야 합니다. 캐시 무효화는 종종 까다로울 수 있으며, 캐시 키의 모든 엣지 케이스를 고려해야 합니다. 10-20ms 정도로 유지된다면 캐싱이 필요하지 않습니다.
  4. 검사에 시간을 측정하세요. 각 확인은 app/services/merge_requests/mergeability/logger.rb 클래스를 통해 시간을 측정하고, 그 후 Kibana에서 확인할 수 있습니다.

클래스들이 함께 작동하는 방법

  1. 병합 가능성 프레임워크를 호출하는 주요 메서드는 def mergeable?DetailedMergeStatusService입니다.
  2. 이러한 메서드는 병합 가능성 확인, 캐싱 및 인스트루먼테이션을 처리하는 RunChecksService 클래스를 호출합니다.

병합 시 검사 통과

병합 시 검사를 통과하려면 다음을 수행해야 합니다:

  1. 클래스에서 확인을 건너뛸 수 있도록 허용합니다.
  2. skipped_mergeable_checks 메서드에서 매개변수 목록에 매개변수를 추가합니다.

향후 작업

  1. 현재 승인 확인의 성능이 느린 것이 주요 관심사입니다. 이 확인을 캐시할 수 있도록 시도했지만, 무효화할 사례가 많으므로 고려해야 할 사례가 많습니다.