GitHub 작업으로 GraphQL 작업 검증

GraphQL의 약속은 다른 방법(예를 들어 REST API)보다 API의 지속적인 발전을 더욱 쉽게 한다는 것이다.비록 API 관리자는 지원하는 유형과 필드에 대한 갑작스러운 파괴적인 변경을 피해야 하지만, 클라이언트 프로그램을 구축하고 있다면, 모든 작업이 요청한 GraphQL API의 현재 교체에 안전하게 적용될 수 있도록 하는 것이 좋습니다.
GitHub Actions는 GitHub 메모리 라이브러리의 특정 활동(예를 들어 푸시 또는 요청)을 연결하여 GraphQL 작업이 이벤트 발생 시 유효하도록 편리하게 한다.이 글은 클라이언트가 GraphQL 모드에 사용하는 모든 GraphQL 작업에 대해 정적 분석을 수행하기 위해 사용자 정의 GitHub 작업을 구축하는 방법을 개괄적으로 기술합니다.워크플로우에서 이 작업을 사용하는 방법도 보여 줍니다.
TL;DR:action repo here와working demo of it in a workflow here를 보실 수 있습니다.

행동 목표와 게임 계획
이 작업을 작성할 때 다음과 같은 수준 높은 목표가 있습니다.

파일이나 .graphql 템플릿 태그

가 포함된 .js 파일에서 모든 GraphQL 작업을 검색하고 검증합니다.

항목에 디렉터리를 지정하고 검색을 시작합니다

.

필요에 따라 디렉터리나 파일을 검색에서 제외

저장소의 동일한 아키텍처 파일 또는 원격 아키텍처

에 대한 작업 검증

필요에 따라 구조를 획득할 때 gql 헤드에 영패

를 발송한다
이러한 목표를 실현하기 위해 저는 GraphQL.js과GraphQL Tools고에 매우 의존합니다.구체적으로 GraphQL 도구는 코드 파일(즉 Authorization 또는 .js 파일에서 GraphQL 작업을 불러오는 기능을 제공한다.또한 .graphql 파일, .graphql 파일 또는 URL에서 로드 모드를 제공하는 기능도 제공합니다.GraphQL.js 라이브러리는 불러오는 패턴에 따라 불러오는 조작 문서를 검증할 수 있는 함수를 제공합니다.
그리고 저는 @actions/core 패키지를 사용하여 각 부분을 한데 놓고 동작을 터치할 때 검증을 실행하고 GitHub 메모리 라이브러리 인터페이스에서 검증 검사의 성공 또는 실패에 대한 피드백을 제공합니다. 어떤 필드나 유형이 잘못되었는지 포함합니다.

워크플로에서 작업 사용
먼저 프로젝트의 the workflow를 설명하기 위해 YAML 파일을 만들어야 합니다(예: .json.
그런 다음 저장소의 파일을 패키지로 체크 아웃하는 작업을 파일에 추가합니다actions/checkout.그리고 작업의 두 번째 단계로 서명한 파일에 대해 검증 작업을 실행할 수 있다.
다음 입력을 지원하도록 GraphQL 작업 유효성 검사 작업을 설계했습니다.

.github/workflows/operations.yml(필수): 검색 작업의 기본 디렉토리(저장소의 루트 디렉토리에 비해)

$GITHUB_WORKSPACE(필수): base_dir/schema_location 파일의 끝점 URL 또는 경로(저장소의 루트에 비해)

.json: 제외할 .graphql 디렉토리/파일 경로의 쉼표 구분 목록excluded_paths과 비교

base_dir: 권한 수여 헤드와 함께 사용하는 영패

이 예는 저장소의 base_dir 분기에 요청을 전송하거나 보낼 때 GraphQL 작업을 검증하는 방법을 보여 준다.이 작업은 저장소token의 로컬 아키텍처 파일을 가리키며 main 디렉토리에서 작업을 찾고 작업 문서를 검색할 때 swapi/schema.graphql 파일을 제외합니다. 이로 인해 오류가 발생할 수 있습니다.

name: Validate GraphQL Operations
on:
  pull_request:
  push:
    branches:
      - main

jobs:
  operations:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v2

      - name: Validate SWAPI operations
        uses: mandiwise/graphql-operation-validation-action@v1
        with:
          schema_location: ${{ github.workspace }}/swapi/schema.graphql
          base_dir: ${{ github.workspace }}/swapi
          excluded_paths: schema.graphql

작업/체크 아웃을 사용할 때는 적어도 swapi를 swapi/schema.graphql 입력으로 지정해야 하지만 항목에 있는 모든 작업이 아래의 특정 하위 디렉토리에 중첩되도록 검색 범위를 좁힐 수 있습니다.검색 작업 시 ${{ github.workspace }} 디렉토리는 자동으로 무시되므로 선택 사항base_dir 입력에 포함할 필요가 없습니다.
이제 분기node_modules를 클릭하거나 PR을 제출하면 GitHub의 저장소에 있는 Actions 탭을 보고 결과를 볼 수 있습니다.작업이 잘못되면 로그에 기록됩니다.

인증 토큰 보내기
필요excluded_paths 헤드의 토큰에 대한 구조 검증 작업이 필요하다면 main 입력값으로 추가할 수 있습니다.

# ...
  - name: Validate GitHub GraphQL API operations
    uses: mandiwise/graphql-operation-validation-action@v1
    with:
      schema_location: https://api.github.com/graphql
      base_dir: ${{ github.workspace }}/github
      token: ${{ secrets.ACCESS_TOKEN }}

헤더는 Authorization 방안으로만 발송됩니다.GitHubusing encrypted secrets in a workflow에 있는 문서를 참고하여 클라이언트 응용 프로그램의 저장소에 영패를 안전하게 저장할 수 있습니다.

로컬에서 실행
개발 환경에서 작업을 확인하시겠습니까, 아니면 저장소로 전송하지 않으시겠습니까?문제 없어요!
act를 사용하여 로컬에서 이 작업을 실행할 수 있습니다.act를 설치한 후 token 로컬 환경의 이전 작업 흐름 예시에서 이 동작을 실행할 수 있지만, 실제로는 GitHub로 코드를 전송할 필요가 없습니다.클라이언트 응용 프로그램의 지속적인 개발 과정에서 로컬에서GraphQL 조작을 테스트하는 데 매우 편리하다.

반갑습니다.
가져오기 모드에는 쿼리introspection가 필요하므로 유효성을 검사하려는 GraphQL API에 내장을 열어야 합니다.따라서 로컬 개발 환경에서 공용 GraphQL API와 함께 사용하거나 모드 파일이 클라이언트 응용 프로그램과 같은 위치에 있을 때 사용하는 것이 가장 적합할 수 있습니다.

요약
이것은 내가 처음으로 GitHub 조작을 시도한 것이고 개발 과정에서 나는 많은 것을 배웠다.GitHub 작업은 매우 강력합니다. 사용자 정의 작업을 만들 때 모든 모바일 위젯을 검색하고 어디서부터 시작해야 할지 알기 어렵지만, 몇 백 줄의 코드만 있습니다. 사용자 정의 작업을 만드는 데 관심이 있다면, 이 동작이 유용한 참고가 되기를 바랍니다.
만약GraphQL과 관련된 모든 작업 절차에서 이 동작을 사용한다면, 본문이나 환매 프로토콜 Issues 의 논평에서 이 동작에 대한 피드백을 듣고 싶습니다.