chore: develop PR on check workflow 작성

[char-yb]

🌱 관련 이슈

• close ⚙️ Pull Request on Check #4

📌 작업 내용

• Pull Request 생성 시 gradle Check 실행

🙏 리뷰 요구사항

• 워크플로에서 추가해야 하거나 수정해야하는 부분 있다면 피드백 부탁드릴게요:)

📚 레퍼런스

gradle-build-action 참고

• gradle-build-action
• build-action 적용 블로그

왜 test가 아닌 check인가? (gradle test vs check)

• https://www.baeldung.com/gradle-test-vs-check

[dbscks97]

PR올릴때 gradle check를 워크플로우로 작성한건 처음보는데 좋은 것 같습니다 ㅎㅎ

[dbscks97]

워크플로우에 해당 PR에 대한 결과를 슬랙에 알림을 보내는 기능을 넣는 건 어떤가요?

[char-yb]

@dbscks97 넵넵 좋습니당
아직 Slack 앱에서 Webhook을 발급받지 않아서 발급받고 진행하도록 할게용

[kwanok]

사소한데 혹시 develop만 지정한 이유가 있을까요?? 마지막 부분에 main, develop 을 제외하는 코드가 있는데 이 부분의 의도가 궁금해요!

[char-yb]

@kwanok develop만 지정한 이유는 main과 별개의 CI workflow를 하기 위함도 있을 수 있지만,
굳이 main 또는 release 브랜치에 작업된 내용을 직접적으로 바로 찌르지 않고 develop에서 CI 과정이 검증되었다고 생각했습니당

main과 develop을 제외하는 코드는 build-action에서 캐시를 읽기전용만을 사용하기 위함이에용

[kwanok]

상세한 설명 감사드려요. 😊 추가적으로 궁금한 게

1. 별개의 workflow로 CI를 돌릴 생각이고
2. 올려주신 야믈에서 watch 할 브랜치가 develop 뿐이라면

cache-read-only 조건문은 불필요하지 않을까...? 생각했어요. 아래와 같이 변경하는 건 어떻게 생각하시나요?

...
    with:
        arguments: check
        cache-read-only: false

[char-yb]

괜찮을 거 같아용
현재 작성된 워크플로는 develop으로 PR을 올렸을 때 CI가 발생되는데, 발생될 일이 없어보이네요:)

다만, main(production), develop으로 CI/CD가 이뤄진 경우에서는 cache-read-only를 사용하려는 의도가 맞을까용??

[kwanok]

아 넵넵 처음에 올려주신 코드를 보고 개인적으로 느낀 점은

1. main, develop 같이 Deploy 까지 수행할 브랜치라면 캐싱을 비활성화해서 빌드가 클린한 상태로 시작하기 때문에 좀 더 안정성이 높고 신뢰성을 제공하기 위한 의도로 생각했구요,
2. 그 외 브랜치는 Push를 여러 번 할 수 있는 환경이라서 캐싱을 활성화해서 Github Actions 리소스를 효율적으로 사용하기 위한 의도로 파악했어요

[char-yb]

넵넵 1번대로 main, develop은

cache-read-only: ${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }}

해당 코드 상태여도 빌드가 클린한 상태로 시작하고, 그 외는 캐싱을 하고 있습니다!

[kwanok]

넵넵 ㅎㅎ 그래서 처음에 드렸던 말은 어차피 develop branch에만 적용되는 워크플로우라서

${{ github.ref != 'refs/heads/main' && github.ref != 'refs/heads/develop' }} 는 항상 false이니, 중복된 조건으로 인한 스크립트의 복잡도를 낮추려는 의도였습니다!

그래서 이 부분은 사소하다고 생각하고 다양하게 해석할 수 있다고 생각해요. 그대로 두어도 된다고 봅니다!

[kwanok]

확인완료~