PR test

PR TEST 검증?

• 특정 브렌치에 PR을 보낼 경우 test를 돌리는 action 이다.

• 이외로 push 할때도 검증이 가능하도록 할 수 있음.

해당 기술을 택한 이유는?

• 누군가는 원인을 찾고 해결해야 했다.

• 예상치 못한 테스트 이슈를 해결하고자 틈틈히 신경써야 하고 개발 일정에 차질이 생기기 시작했다. 그리고 pr이 쌓여 develop branch에 머지하게 되면 pr을 역추적하여 원인을 찾아야만 했다.

• 그래서 PR을 통해 머지 하기 전에 테스트 코드를 체크후 각 pr에 독립적으로 원인을 해결할 수 있도록 분리했다. ‼️

PR TEST 관련 중요 키워드

• 하나 이상의 작업을 실행하는 구성 가능한 자동화 프로세스 이다,.

• 워크플로는 레포지토리에 체크인된 yaml file에 의해 정의되면 레포지토리의 이벤트에 의해 트리거 될 때 실행되거나 수동으로 또는 정의된 일정에 트리거 될 수 있다.
• 트리거 : 어느 특정한 동작에 반응해 자동으로 필요한 동작을 실행하는 것이다.

Workflows are defined in the .github/workflows  directory in a repository, and a repository can have multiple workflows, each of which can perform a different set of tasks.

어떻게 사용하는지

workflow 작성하기 ‼️

• overview flow[전반적 흐름]
1. pr 감지
2. 브렌치 판별
3. gradle 환경 test 시작 [gradle이 아닐 수도 있음.]
• test가 성공할 경우 pr open 상태 유지
• test가 실패할 경우 pr close 상태로 변경 후 comment를 남긴다.

• 최상단 프로젝트 파일 밑에 github안에 workflow 디렉토리를 생성하고 pr-test.yml 파일을 생성한다
• yml 뼈대 코드

name : // ${workflow_name}
on: // event 정의 [트리거 정의]
  pull_request: //${push 도 올수 있음.}
    branches:
      - ${branch_name}
      - ${another_branch_name}

jobs: // 작업 내용 모음 == steps들의 묵음
  test:
    runs-on: ubuntu-latest [실행 환경]
    steps: // job이 가질 수 있는 동작의 나열, step은 독립적인 프로세스를 가진다.
    uses: // 해당 step에 사용할 액션(행위)
    with: // 해당 acition에 의해 정의되는 input 파라미터, ket/value로 pair로 구성

내가 작성한 pr test 코드

name: PR Test

on:
  pull_request:
    branches:
      - develop
			- main

jobs:
  test:
    runs-on: ubuntu-latest //환경
    steps:
      - uses: actions/checkout@v2

      - name: Set Up JDK 17
        uses: actions/setup-java@v1
        with:
          java-version: 17

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Test with Gradle
        run: ./gradlew test // ./gradlew --info test 이렇게 하면 로그가 엄청 쏟아짐

      - name: if fail
        uses: actions/github-script@0.2.0
        with:
          github-token: ${{github.token}}
          script: |
            const ref = "${{github.ref}}"
            const pull_number = Number(ref.split("/")[2])
            await github.pulls.createReview({
              ...context.repo,
              pull_number,
              body:"테스트코드를 다시 확인해주세요. ",
              event: "REQUEST_CHANGES"
            })
            await github.pulls.update({
              ...context.repo,
              pull_number,
              state: "closed"
            })
        if: failure()

Contexts - GitHub Docs

Contexts are a way to access information about workflow runs, runner environments, jobs, and steps. Each context is an object that contains properties, which can be strings or other objects. Contexts, objects, and properties will vary significantly under different workflow run conditions. For example, the matrix context is only populated for jobs in a matrix.

https://docs.github.com/en/actions/learn-github-actions/contexts#job-status-check-functions

==== build.gradle ====

test {
    testLogging {
        events "PASSED", "SKIPPED", "FAILED"
    }
}

📌REFER

GitHub Actions 로 풀리퀘스트 test 검증하기

이번엔 전에 배웠던 기초적인 actions의 문법으로 간단한 workflow를 만들어보겠습니다. 특정 브랜치에 pr을 보낼 경우 test를 돌리는 action을 작성해보도록 하겠습니다! workflow를 만들때는 말 그대로 흐름을 미리 생각해두고 코드로 구현하면 더 쉬운것 같다. 순서대로 흐름을 나열해보면 pr을 감지한다. pr을 보낸 브랜치를 판별한다. jest로 코드를 test한다. test가 성공할 경우 pr을 그대로 open.

https://velog.io/@adam2/GitHub-Actions-%EB%A1%9C-%ED%92%80%EB%A6%AC%ED%80%98%EC%8A%A4%ED%8A%B8-test-%EA%B2%80%EC%A6%9D%ED%95%98%EA%B8%B0

• gradle test task naming

[testing] Gradle : 실시간으로 콘솔에 테스트 결과를 표시하는 방법

내가 실행 하는 동일한 콘솔에서 테스트 결과 (system.out / err, 테스트중인 구성 요소의 로그 메시지) 를보고 싶습니다. gradle test 그리고 테스트가 완료 될 때만 생성되는 테스트 보고서를보기 위해 테스트가 완료 될 때까지 기다리지 마십시오. 답변 명령 행에서 INFO 로깅 레벨로 Gradle을 실행할 수 있습니다. 실행중인 각 테스트의 결과를 보여줍니다.

http://daplus.net/testing-gradle-%EC%8B%A4%EC%8B%9C%EA%B0%84%EC%9C%BC%EB%A1%9C-%EC%BD%98%EC%86%94%EC%97%90-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B2%B0%EA%B3%BC%EB%A5%BC-%ED%91%9C%EC%8B%9C%ED%95%98%EB%8A%94-%EB%B0%A9/

• github workflow create guide

About workflows - GitHub Docs

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

https://docs.github.com/en/actions/using-workflows/about-workflows

• gradle workflow 예시

[CI/CD] Github Actions 기본개념과 사용법 정리

Github Actions는 Microsoft에서 Github을 인수한 뒤 출시된 CI 솔루션이다. Github과 연동하여 PR 이벤트뿐만 아니라 다양한 이벤트에 trigger 될 수 있는 다양한 작업을 정의할 수 있다. 또한 다양한 action들이 마켓플레이스에 공개되어 있어서 쉽게 workflow를 작성할 수 있다는 점과 CI 서버를 따로 설치하지 않고도 Github에서 제공하는 클라우드 호스팅을 통해 빠르게 CI파이프라인을 구축할 수 있다는 장점이 있다.

https://jh-labs.tistory.com/416