@khg0712 안녕하세요! 병합전에 해당 변경 관련하여 운영진분들과 함께 논의해보았습니다!. 저희 생각에는 이러한 워크플로우의 변경 참여자들의 경험에 어떤 영향을 주는지에 대해서 고민이 좀 더 필요한 것 같습니다. 저희 생각으로는 단순히 체크 수준이 아니라 참여자를 대신에서 직접 commit을 할 경우, 참여자를 이를 모른 체로 로컬에서 다른 commit을 했을 경우, conflict로 이어질 가능성이 높다고 여겨지는데 혹시 이 부분에 대해서 고려해보셨을까요?

@khg0712 안녕하세요! 병합전에 해당 변경 관련하여 운영진분들과 함께 논의해보았습니다!. 저희 생각에는 이러한 워크플로우의 변경 참여자들의 경험에 어떤 영향을 주는지에 대해서 고민이 좀 더 필요한 것 같습니다. 저희 생각으로는 단순히 체크 수준이 아니라 참여자를 대신에서 직접 commit을 할 경우, 참여자를 이를 모른 체로 로컬에서 다른 commit을 했을 경우, conflict로 이어질 가능성이 높다고 여겨지는데 혹시 이 부분에 대해서 고려해보셨을까요?

지나가다 아이디어가 떠올라서 간단하게 공유만 드려요~

현재처럼 CI가 단순 실패만 하지 않고 파일 끝 개행 누락 시 PR에 코멘트를 남기는 방식으로 개선하면
Conflict도 방지되고, 개행이 있을 경우 알림을 주어 참여자 경험을 조금 더 부드럽게 만들 수 있지 않을까 합니다 🤔

• create a review comment for a pull request 를 참고
• API를 호출할 때 suggestion을 body에 남기면 리뷰를 보고 손쉽게 즉각 반영하는것도 가능하지 않을까 싶어요 ㅎㅎ

예를 들어, 아래와 같이 파일의 마지막 줄 번호를 구하고, 해당 줄에 코멘트를 달아주는 방식으로 할 수도 있지 않을까 싶었어요!
(실제 정확하게 동작하는 코드인지 확인을 하지 않아서 수도 코드로 봐주세요!)

      - name: Check for missing end line breaks
        env:
           ...
        run: |
           ...
          echo "## 줄바꿈 누락 파일" >> $GITHUB_STEP_SUMMARY

          for file in $files; do
            if [ -f "$file" ]; then
              if [ -s "$file" ] && [ "$(tail -c 1 "$file" | wc -l)" -eq 0 ]; then
                echo "❌ 줄바꿈 누락: $file"
                echo "- $file" >> $GITHUB_STEP_SUMMARY
                success=false

               # 마지막 줄 번호 구하기
               last_line=$(wc -l < "$file")
                [ "$last_line" -eq 0 ] && last_line=1

                # 코멘트 payload 구성
                payload=$(jq -n \
                  --arg body "❌ 파일 끝에 줄바꿈이 없습니다." \
                  --arg commit_id "${{ github.event.pull_request.head.sha }}"
                  --arg path "$file" \
                  --argjson line "$last_line" \
                  '{body: $body, commit_id: $commit_id, path: $path, line: $line, side: "RIGHT"}')

                 curl --silent --fail --show-error \
                  -H "Accept: application/vnd.github+json" \
                  -H "Authorization: Bearer $GITHUB_TOKEN" \
                  -H "X-GitHub-Api-Version: 2022-11-28" \
                  -d "$payload" \
                  "https://api.github.com/repos/${{ github.repository }}/pulls/${PR_NUMBER}/comments" \
                  || echo "⚠️ GitHub 코멘트 등록 실패 (권한 문제 또는 잘못된 commit_id)"

              else
       ...

쓰다보니 이 방식을 사용할 때 몇 가지 신경써야하는 부분이 있더라고요..!

• API 호출이 빈번하면 GitHub API rate limit에 걸릴 수 있다
• 매번 workflow가 돌 때마다 같은 파일에 같은 코멘트가 계속 달릴 수 있습니다 😅
• PR 코멘트를 쓰려면 workflow 권한에 write 권한이 필요할 것 같아요.

저는 아이디어만 제공하고 가보겠습니다..! 제가 잘못 이해한 부분이 있거나, 궁금한 부분이 있으면 코멘트로 남겨주세요! 화이팅입니다~! 💪

제가 생각했던 기존 PR 워크 플로우의 불편한 부분은 다음과 같은 흐름으로 느껴졌습니다.

1. WIKI에 참여자가 알아야 하는 정보가 많은데 파일 개행관련 규칙은 참여자가 알지 않더라도 시스템적으로 자동화하면 더 좋겠다.
2. 단순히 코멘트나 Ci 실패로 알려줘도 참여자가 인지할 수는 있겠으나 사용자가 해당 알림에 대해 팔로업을 해야 하고 비동기 소통이 기반인 커뮤니티에서 이런 워크플로우는 흐름을 더 느리게 만들 수 있어보인다.
3. 파일 N개에 대해서 수동으로 파일 개행을 추가하는 것이 생각보다 불편한데 해당 작업이 복잡한 파일변경이 아니기 때문에 자동화하면 편리하겠다.

만약 로컬 변경과 리모트 소스의 차이로 인해 컨플릭이 나는 것이 걱정되신다면 ci에서는 파일 컨벤션 검사만 하고
이런 자동화는 pre-commit hook이나 pre-push 훅에서 처리하면 해당 문제는 없어질 것 같습니다.

제 요점은 참여자들의 인지 부하를 줄이고 자동화가능한 영역은 자동화하면 좋을 것 같다 였습니다.

@khg0712 자동 개행 추가가 참여자 편의에 도움이 된다는 점 충분히 공감합니다. 관련 문제 인지하시고 PR 작성해주셔서 감사드립니다!
다만, CI가 직접 커밋이나 푸시를 수행하는 구조는 지양하는 것이 좋을 것 같습니다!.
휴고님이 주신 대안처럼 pre-commit hook이나 pre-push 단계로 옮기는 방향이 더 적절해 보입니다!