예시를 통해 홍보 검사를 예쁘게 하다

이전에 어떤 형식의 지속적인 통합 프로젝트에 종사한 적이 있다면, 코드를 버전 제어에 제출할 때 실행하는 검사의 개념을 익힐 수 있습니다.
모르는 사람들에게는 코드의 제출/업데이트에 응답하기 위해 실행되는 작업입니다. 이 작업들은 테스트, linting 검사, 대량의 다른 코드 검증을 실행할 수 있습니다.대부분의 설정에서 분기는 일반적으로pullreview 프로세스로 보호되며, 이 프로세스는 제안된 코드 변경을 검토하고 코드 라이브러리에 통합하기 전에 검사할 수 있습니다.
본고에서 GitHub Actions를 사용하여 간단한 지속적인 통합 작업을 설정합니다. 이 작업은 유행하는 Ktlint 라이브러리를 실행하고, ReviewDog이라는 도구를 사용하여 쉽게 이해할 수 있는 방식으로 출력을 Pull 요청에 추가합니다.

크트린트가 그라델을 만났다
CLI에서 Ktlint를 실행할 수 있지만 Gradle 작업으로 소개하는 것을 더 좋아합니다.이런 식으로 모든 설정을 제공합니다. (비록 이런 상황에서는 없지만) 프로젝트 자체에 머무르게 하고, 팀원들과 같은 출력을 실행할 수 있도록 합니다.또 다른 장점은 이 작업을 기존android linting 작업에 연결할 수 있다는 것이다. CLI에서 실행되는 일만 절약하면 된다.
내가 선택한 임무는 다음과 같습니다.
kotlinter
이 특수한 플러그인은 성능이 매우 좋습니다.gradles 증량으로 시스템을 구축하고Gradle Worker API를 병행화한 linting 작업을 사용합니다. 여러 모듈의 작업 공간이 있으면 매우 빠릅니다.결국 이런 검사는 자주 이뤄지기 때문에 1년에 10~15초를 절약할 수 있다.
나는 여기에 설정을 소개하지 않을 것이다. 너는 위의 링크를 클릭할 수 있고, 심지어는 나의 예시 프로그램을 보면 아래의 블로그 글을 지원할 수 있다.
설치가 완료되었다고 판단되면 다음 작업을 실행하여 확인합니다.gradle lintKotlin오류가 발생하면 오류를 자동으로 수정할 수 있는 다른 작업이 있습니다.gradle formatKotlin이 작업은 일부 문제를 해결할 수 없기 때문에 피드백을 받아서 스스로 바로잡아야 합니다.

이 작업을 끌어오기 요청에서 실행합니다
GitHub 작업에서 모든 작업 흐름을 실행하려면 폴더에yaml 파일을 설치하십시오.github/프로젝트 루트 디렉터리와 관련된 작업 흐름, 실행할 명령.
예를 들면 다음과 같습니다.
.github/workflows/code-quality.yml

name: Code Quality
on: [pull_request]
jobs:
  ktlint:
    name: Run ktlint
    runs-on: ubuntu-latest

    steps:
      - name: Clone repo
        uses: actions/checkout@master
        with:
          fetch-depth: 1

      - name: Ktlint
        run: gradlew lintKotlin

이것으로 충분합니다. linter를 실행하고 PR에 대한 검사를 제공하여 코드를 검증합니다.그러나 우리는 다음과 같은 의미 있는 피드백을 얻기 위해 몇 가지 일을 하고 싶다.

...

예쁜 부분...
그래서 우리는 어떻게 해야 하는지 안다.

Gradle

을 사용하여ktlint 실행

CI

에서 Gradle 작업 실행
현재, 리뷰 dog를 사용하여gradle lint 작업의 결과로pull 요청에 대한 평론을 하는 방법을 알아야 합니다.
따라서 이 linting 작업의 출력을 이해하는 것이 매우 중요하다.기본적으로kotlinter는 보고 파일을 만들고 모듈마다 보고 파일을 생성합니다.modules generated build 폴더에서 이 보고서를 찾을 수 있습니다. (즉, 이 보고서를 앱에서 실행하면 app/build/...)에서 보고서를 찾을 수 있습니다.이 파일들을 모아서 리뷰 독에 전달할 수 있지만, 발견된 오류를 stderr에 기록할 수도 있습니다.셸 스크립트를 통해 이 출력을 맞춤형으로 설정하여 ReviewDog에 전송할 수 있으며, 모든 보고서를 모으는 작업을 절약할 수 있습니다.
따라서 개가 그것을 받아들일 수 있도록 우리가 필요로 하는 상장 보고서의 모양을 살펴보자.
"reviewdog는 stdin에서 온 컴파일러나linter 결과를 받아들이고'errorformat'와 같은 스캔-f를 사용하여 이를 해석합니다. 이것은Vim의 errorformat 기능의 포트입니다."
간단하게 말하자면, 우리가 리뷰 dog 표준 입력에 입력한 줄마다 반드시 특정한 형식이 있어야 한다. 우리는 어느 정도에 이런 형식을 규정할 수 있지만, 최종적으로 우리는 반드시 errorformat을 따라야 한다.
예를 들어 "efm"명령줄 매개 변수를 통해 review dog에 다음 형식이 필요하다고 알려주면 다음과 같습니다.%f:%l:%c:%t: %m복습견은 각 줄의 격식을 다음과 같이 원한다.{file}:{line number}:{column number}:{error type}: {message}고맙게도, lint Kotlin 임무의 stderr는 기본적으로 이미 이런 형식이다.
저희가 관심 있는 라인만 거르면 돼요.grep 'Lint error > '텍스트 "Lint error >"을 오류 형식으로 바꾸고, 이 예에서는 오류 형식을 "e"로 바꿀 수 있습니다.sed 's/ Lint error > /e: /g'너는 포맷 교체의 유형과 의미에 대해 더 많이 읽을 수 있다here
보다
.github/scripts/check.sh

#!/usr/bin/env bash

./gradlew lintKotlin 2>&1 | grep 'Lint error > ' | sed 's/ Lint error > /e: /g' | reviewdog  \
-name="ktlint" \
-reporter=github-pr-review \
-efm="%f:%l:%c:%t: %m" \
-level=error \
-filter-mode=nofilter \
-fail-on-error

스크립트가 CI에서 실행될 때 실행 가능하기를 원하면git에 실행 가능한 권한을 표시해야 합니다.git 업데이트 인덱스 --chmod=+x입니다.github/스크립트/검사.야유

이 모든 것을 함께 놓아라
이전 yaml 파일을 다음과 같이 업데이트합니다.
.github/workflows/code-quality.yml

name: Code Quality
on: [pull_request]
jobs:
  ktlint:
    name: Run ktlint
    runs-on: ubuntu-latest

    steps:
      - name: Clone repo
        uses: actions/checkout@master
        with:
          fetch-depth: 1

      - name: Install Review Dog
        uses: reviewdog/action-setup@v1
        with:
          reviewdog_version: latest

      - name: Ktlint
        env:
          REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.github_token }}
        run: .github/scripts/check.sh

너무 많은 세부 사항이 언급되지 않은 상황에서, 리뷰 독을 설치하고, 이전에 작성한 bash 스크립트를 실행하기 위한 새로운 작업을 추가했습니다. (이 비밀을 설정할 필요가 없습니다. 이 비밀은 귀하께 제공됩니다.)
예를 들어 프로젝트here를 들었습니다. 만약에 곤경에 빠진 사람이 그것을 복제하고 싶다면 이 환매협정의 게시물에 언급된 홍보를 보실 수 있습니다.