Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: develop PR on check workflow 작성 #7

Merged
merged 6 commits into from
Jun 22, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions .github/workflows/develop-pull-request-on-check.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
name: Pull Request on Check
on:
pull_request:
branches:
- develop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

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

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Member

@kwanok kwanok Jun 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

넵넵 1번대로 main, develop은

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

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

Copy link
Member

@kwanok kwanok Jun 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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

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

jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
java-version: [ 17 ]
steps:
- name: Checkout code
uses: actions/checkout@v3

- name: Set up Java
uses: actions/setup-java@v3
with:
java-version: ${{ matrix.java-version }}
distribution: 'zulu'

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

- name: Setup Gradle
uses: gradle/gradle-build-action@v3
with:
arguments: check
cache-read-only: false
## slack 알람
- name: Slack Alarm
uses: 8398a7/action-slack@v3
with:
status: ${{ job.status }}
author_name: GitHub-Actions CI/CD
fields: repo,message,commit,author,ref,job,took
env:
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} # required
if: always() # Pick up events even if the job fails or is canceled.
Loading