Conversation
CI 속도 개선을 위함
easyhooon
changed the title
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughGitHub Actions 안드로이드 CI 워크플로우에 push 트리거가 추가되고, Gradle 액션이 Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 시
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/android-ci.yml (1)
42-43: push 시 두 잡 모두 캐시 쓰기를 허용하면 캐시 churn이 커질 수 있습니다.용량 절약이 목표라면
stability_check는 read-only로 고정해도(읽기 재사용 유지) 저장소 사용량을 더 안정적으로 줄일 수 있습니다.♻️ 제안 수정 (`stability_check`만)
- cache-read-only: ${{ github.event_name == 'pull_request' }} + cache-read-only: trueAlso applies to: 85-86
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/android-ci.yml around lines 42 - 43, The workflow currently allows cache writes on push which can increase cache churn; update the workflow so the stability_check job sets cache-read-only to true (i.e., keep read-only behavior regardless of github.event_name) by modifying the stability_check job's cache-read-only setting (reference job name "stability_check" and the "cache-read-only" key) so pushes do not write caches while other jobs can remain unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/android-ci.yml:
- Around line 39-40: Update the incorrect comments for the setup-gradle@v4
action's cache-cleanup option: change the comment text currently saying
"default: never" to the correct "default: on-success" for both occurrences (the
comment near the cache-cleanup: on-success setting and the second instance
further down), ensuring the comment next to the cache-cleanup key and any
explanatory comment blocks reflect the actual default behavior of
setup-gradle@v4.
---
Nitpick comments:
In @.github/workflows/android-ci.yml:
- Around line 42-43: The workflow currently allows cache writes on push which
can increase cache churn; update the workflow so the stability_check job sets
cache-read-only to true (i.e., keep read-only behavior regardless of
github.event_name) by modifying the stability_check job's cache-read-only
setting (reference job name "stability_check" and the "cache-read-only" key) so
pushes do not write caches while other jobs can remain unchanged.
.github/workflows/android-ci.yml
Outdated
| # 빌드 성공 시 미사용 캐시 엔트리 자동 정리 (default: never) | ||
| cache-cleanup: on-success |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's examine the actual file to see the context
cat -n .github/workflows/android-ci.yml | sed -n '35,45p'Repository: YAPP-Github/Reed-Android
Length of output: 714
🏁 Script executed:
# Also check lines 80-90 for the other occurrence mentioned
cat -n .github/workflows/android-ci.yml | sed -n '80,90p'Repository: YAPP-Github/Reed-Android
Length of output: 662
🌐 Web query:
setup-gradle@v4 cache-cleanup default value documentation
💡 Result:
For gradle/actions/setup-gradle@v4, the cache-cleanup input defaults to on-success (i.e., it only runs cache cleanup when all Gradle builds in the job succeed). You can set it to always or never. [1]
This behavior (and that cache cleanup is enabled by default in v4) is also noted in the v4 deprecation/upgrade guide, where the old boolean gradle-home-cache-cleanup input was replaced by cache-cleanup. [2]
Sources: [1], [2]
cache-cleanup 주석의 기본값을 수정하세요.
setup-gradle@v4 액션의 cache-cleanup 기본값은 on-success이지만, 주석에는 default: never로 잘못 표기되어 있습니다. 두 위치(39-40, 83-84)의 주석을 모두 수정해야 합니다.
수정 방법
- # 빌드 성공 시 미사용 캐시 엔트리 자동 정리 (default: never)
+ # 빌드 성공 시 미사용 캐시 엔트리 자동 정리 (default: on-success)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # 빌드 성공 시 미사용 캐시 엔트리 자동 정리 (default: never) | |
| cache-cleanup: on-success | |
| # 빌드 성공 시 미사용 캐시 엔트리 자동 정리 (default: on-success) | |
| cache-cleanup: on-success |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/android-ci.yml around lines 39 - 40, Update the incorrect
comments for the setup-gradle@v4 action's cache-cleanup option: change the
comment text currently saying "default: never" to the correct "default:
on-success" for both occurrences (the comment near the cache-cleanup: on-success
setting and the second instance further down), ensuring the comment next to the
cache-cleanup key and any explanatory comment blocks reflect the actual default
behavior of setup-gradle@v4.
There was a problem hiding this comment.
default값 어디서 어떻게 확인할 수 있어?
There was a problem hiding this comment.
@easyhooon GitHub Actions의 default 값을 확인하는 방법은 다음과 같습니다:
1. 액션 저장소의 action.yml 파일 확인
가장 정확한 방법은 해당 액션의 GitHub 저장소에서 action.yml (또는 action.yaml) 파일을 직접 확인하는 것입니다.
setup-gradle@v4의 경우:
- 저장소: https://github.com/gradle/actions
- action.yml 경로: https://github.com/gradle/actions/blob/main/setup-gradle/action.yml
여기서 inputs 섹션을 보면 각 파라미터의 default 값이 명시되어 있습니다:
cache-cleanup:
description: ...
required: false
default: 'on-success'2. 공식 문서 확인
- Gradle Actions 문서: https://github.com/gradle/actions/blob/main/docs/setup-gradle.md
- 마이그레이션 가이드에서 v2 → v4 변경사항 확인
3. 실전 팁
- GitHub에서 액션 버전을 명시할 때 (예:
@v4), 해당 버전의 태그나 릴리스를 찾아가서 확인 - 액션 사용 시
@뒤의 버전/태그/커밋을 클릭하면 해당 시점의 코드로 이동 가능
현재 케이스에서 cache-cleanup의 default 값은 실제로 on-success가 맞습니다! 👍
There was a problem hiding this comment.
default가 on-success면 굳이 설정 코드 남길필요없잖아 주석만 남기고 코드는 지워야겠네
seoyoon513
left a comment
seoyoon513
left a comment
There was a problem hiding this comment.
캐시 적용 시 시간 단축 얼마나 될지 기대됩니다 👍👍
첫 빌드시간은 그대로 일텐데 그 이후에 리뷰 반영이나, 추가 커밋시 시간은 많이 줄어들것같습니다. 다른 사이드 플젝에서 리뷰 반영 및 추가 때문에 깃허브 액션 무료 2000분을 다 소진해서 현재 못돌리고있는데 기대가 되네요 ㅎ |
엥? 11분 걸렸는데? 그대론데?
|
2 participants
CI 속도 개선을 위함
🔗 관련 이슈
📙 작업 설명
gradle/gradle-build-action@v2에서gradle/actions/setup-gradle@v4로 교체cache-read-only: PR에서는 캐시 읽기만 허용(read-only), push(develop/main)에서만 캐시 갱신하여 용량 절약cache-cleanup: on-success: 빌드 성공 시 미사용 캐시 엔트리 자동 정리🧪 테스트 내역 (선택)
💬 추가 설명 or 리뷰 포인트 (선택)
태스크
Gradle에서 태스크는 빌드 과정의 각 개별 작업 단위입니다.
assembleDebug를 실행하면 내부적으로 이런 태스크들이 순서대로 실행됩니다:
이게 모듈마다 있으니까 core, feature, app 각각에 이런 태스크들이 존재합니다.
빌드 캐시는 이 태스크 하나하나에 대해 "입력이 이전과 같으면 결과를 재사용"하는 방식입니다. 예를 들어 core 모듈의 소스를 안 건드렸으면
core:compileDebugKotlin태스크는 캐시 hit → 스킵됩니다.태스크에서 입력의 의미
여기서 입력은 태스크가 실행될 때 참조하는 모든 것입니다.
compileDebugKotlin 태스크를 예로 들면:
입력:
출력:
Gradle이 이 태스크를 실행하기 전에 입력들의 해시값을 계산합니다.
이전 빌드 때와 해시가 같으면 "소스 안 바뀌었으니 다시 컴파일할 필요없다"고 판단하고 캐시된 출력(.class 파일)을 그대로 쓰는 겁니다.
processDebugResources도 마찬가지로:
리소스를 안 건드렸으면 → 해시 동일 → 캐시 hit → 스킵
결국 "코드나 설정을 바꾼 부분과 관련된 태스크만 다시 실행된다"는 뜻입니다.
Summary by CodeRabbit
릴리스 노트