초기 작업은 더 잘 정의된 머지 가능성 프레임워크에서 시작되었습니다.

원래 머지 가능성에 관한 지식은 백엔드와 프론트엔드 전반에 분산되어 있었습니다. 이 작업은 머지 가능성 기준 일부를 백엔드의 동일한 위치로 통합하기 위한 것입니다. 이를 통해 프론트엔드는 단순히 API를 소비하고 오류를 표시하기만 하면 됩니다.

새 검사 추가#

새로운 머지 검사를 추가할 때는 몇 가지 사항을 결정해야 합니다:

• 이 검사를 건너뛸 수 있는지, 그리고 검사 통과 시 머지 기능의 일부인지 여부

• 이 검사를 캐시할 수 있는지 여부

그렇다면, 적절한 캐시 키는 무엇인지 결정해야 합니다.

• 이 검사에 검사를 켜거나 끌 수 있는 설정이 있는지 여부

이 질문들에 답한 후 새 검사를 생성할 수 있습니다.

머지 가능성 검사는 app/services/merge_requests/mergeability/ 아래에 있습니다.

• 새 검사를 생성하기 위해 다음을 기반으로 사용할 수 있습니다:

# frozen_string_literal: true
module MergeRequests
  module Mergeability
    class CheckCiStatusService < CheckBaseService
       identifier :ci_must_pass # Identifier used to state which check failed
       description 'Checks whether CI has passed' # Description of the check returned through GraphQL

      def execute
        # If the merge check is behind a setting, we return inactive if the setting is 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?
        # Here we can check for the param or return false if it's not skippable
        # Skippability of an MR is related to merge when checks pass functionality
        params[:skip_ci_check].present?
      end

      # If we return true here, we need to create the method def cache_key and provide
      # an appropriate cache key that will invalidate correctly.
      def cacheable?
        false
      end
    end
  end
end

• def mergeable_state_checks 메서드에 새 검사를 추가합니다.

• GraphQL enum app/graphql/types/merge_requests/detailed_merge_status_enum.rb에 새 검사를 추가합니다.

• bundle exec rake gitlab:graphql:compile_docs를 사용하여 GraphQL 문서를 업데이트합니다.

• doc/api/merge_requests.md의 API 문서를 업데이트합니다.

• 새 메시지를 지원하도록 프론트엔드를 업데이트합니다: app/assets/javascripts/vue_merge_request_widget/components/checks/message.vue.

고려사항#

• 건너뛸 수 있어야 하는지 여부. 검사 통과 시 머지 작업의 일부라면 건너뛸 수 있는 검사를 추가해야 합니다. 그렇지 않으면 false를 반환해야 합니다.

• 성능: 이 머지 가능성 검사는 매우 빈번하게 실행되므로 성능이 중요한 고려사항입니다. 새 머지 가능성 검사의 성능을 확인하는 것이 중요합니다. 일반적으로 10~20ms 정도를 예상합니다.

• 캐싱도 옵션입니다. def cacheable? 메서드를 true를 반환하도록 설정할 수 있으며, 이 경우 특정 검사의 캐시 키를 설정하는 def cache_key 메서드를 추가로 생성해야 합니다. 캐시 무효화는 까다로울 수 있으며, 캐시 키의 모든 엣지 케이스를 고려해야 합니다. 타이밍을 10~20ms 정도로 유지한다면 캐싱은 필요하지 않습니다.

• 검사 시간을 측정합니다. app/services/merge_requests/mergeability/logger.rb 클래스를 통해 각 검사 시간을 측정하며, Kibana에서 확인할 수 있습니다.

클래스가 함께 작동하는 방식#

• 머지 가능성 프레임워크를 호출하는 주요 메서드는 def mergeable?와 DetailedMergeStatusService입니다.

• 이 메서드들은 머지 가능성 검사의 반복, 캐싱 및 계측을 처리하는 RunChecksService 클래스를 호출합니다.

검사 통과 시 머지#

검사 통과 시 머지 기능에 검사를 추가하려면 다음을 수행해야 합니다:

• 클래스에서 검사를 건너뛸 수 있도록 허용합니다.

• skipped_auto_merge_checks 메서드의 목록에 매개변수를 추가합니다.

향후 작업#

• 현재 승인 검사의 낮은 성능이 주요 우려 사항입니다. 이 검사를 캐시 가능하게 만들려고 시도했지만, 무효화 시점과 관련하여 고려해야 할 엣지 케이스가 많습니다.