PR language labeling 워크플로 수행시 403 Forbidden 오류 발생

[bbFactory]

배경

• 이전 PR을 통해 작업자의 Pull Request 에 사용된 언어를 감지하고, 감지된 언어의 label 을 PR 에 추가하는 워크플로를 등록하였습니다.
• 워크플로에 요구되는 permissions 이 있었고 이들을 모두 작성해주었으나, 지속적으로 403 Forbidden 오류가 발생하였습니다.
  • PR 에 label 을 추가하기 위해서는 issues 또는 pull-requests 의 쓰기(write) 권한이 필요합니다.
  • X-Accepted-GitHub-Permissions: GitHub API 특정 엔드포인트 접근시 필요한 권한을 알려주는 헤더 (관련 문서).
  • 워크플로 실패 Response
    
• data.message 에서 알 수 있듯, Response 에서는 Resource not accessible by integration 이라며 리소스 접근이 불가하다고 합니다.
• 결국 GitHub 서버에서 요청한 permissions 를 정상적으로 전달하였음에도(기존 워크플로에서는 pull-requests: write 적용), 오류가 지속적으로 발생하였으므로 그 이유를 찾아야 했습니다.

문제 원인

• 최초 테스트 시에는 base repo 와 working repo 를 동일하게 사용했습니다. 즉, fork 하지 않은 상태에서 PR을 작성하여 테스트를 진행하였습니다.
  • repo 가 동일하므로, 작업 repo 로부터 시작된 PR 워크플로에서 base repo 의 컨텍스트를 사용하는 데 문제가 없었습니다.
  • 이후 테스트가 정상적으로 수행되는 걸 확인한 후 leetcode-study Repo 에 PR 을 열었습니다.
• 그러나 실제로는 작업자가 fork 를 수행한 후에, 작업을 PR 로 만든다는 것을 깨닫고 테스트를 다시 수행하였습니다.
  • fork 할 경우, PR 의 base repo 와 작업 repo 가 달라지는데, 작업자의 워크플로에서는 보안상의 이유로 base repo 의 민감 정보를 얻지 못하도록 GitHub 이 막아두고 있었습니다 (관련 문서).
  • 결과적으로 label 을 추가하는 API 는 GitHub Token, PR Context 등 민감 정보를 사용하므로, fork 기반 워크플로가 항상 실패했습니다.

해결 방법 및 한계

• 위 문제의 해결 방법으로 GitHub 에서는 pull_request_target 이벤트를 소개하고 있습니다 (관련 문서 Note 참고) (기존 워크플로의 pull_request 이벤트를 대체하면 됨).
• 개인 repo의 PR에서 위 이벤트를 테스트해보았는데, 작업 repo 에서 base repo 컨텍스트를 사용할 수 있다는 것을 확인할 수 있었습니다.
  • 아래 이미지에서 PR 에 java label 이 추가된 걸 확인할 수 있습니다.
    
• 그러나 label 을 추가하기 위해 base repo의 민감 정보를 굳이 얻어야 할까 싶어, leetcode-study repo 에서는 pull_request_target 이벤트를 사용하지 않고자 합니다.

대안

• 그럼에도 자동 labeling 에 대한 니즈가 있을 경우, base repo 내에서 워크플로를 만드는 방법이 있을 듯합니다.
  • 예) 워크플로로 스케줄 잡을 만들어, 하루에 한 번 Opened PR 목록에 언어 label 을 붙이는 방식 등
• 하지만 이렇게까지 해야 하나 싶기도 해서.. 다른 분들의 의견을 들어봐야할 것 같습니다.. ㅎㅎ

[DaleSeo]

@bky373 이거 이슈를 닫으셨네요? 아 제가 방금 PR을 병합해서 닫혔군요? 다시 열겠습니다 그럼 😅

P.S. 혹시 bbFactory도 @bky373 님 계정이신가요?

[DaleSeo]

• 그럼에도 자동 labeling 에 대한 니즈가 있을 경우, base repo 내에서 워크플로를 만드는 방법이 있을 듯합니다.

  • 예) 워크플로로 스케줄 잡을 만들어, 하루에 한 번 Opened PR 목록에 언어 label 을 붙이는 방식 등

• 하지만 이렇게까지 해야 하나 싶기도 해서.. 다른 분들의 의견을 들어봐야할 것 같습니다.. ㅎㅎ

저는 개인적으로 "자동화를 위한 자동화"나 "성급한 자동화"를 경계하는 편입니다. 자칫하면 자동화의 효용은 불명확해지고 유지보수 비용만 증가시킬 수 있기 때문입니다. PR에 언어 레이블을 다는 작업의 경우, 지금까지 올라온 PR들을 보면 반드시 자동화가 필요한지 의구심이 살짝 들기도 합니다. 특별히 부탁드리지도 않았는데도 다들 자발적으로 언어 레이블을 잘 달아주시는 것 같아요. 따라서 저는 멤버들이 레이블 다는 게 귀찮다 불편하다 이러한 피드백이 있을 때 자동화를 해도 늦지 않을까 하는 생각이 듭니다.

그럼에도 불구하고 이번 건은 여태까지 @bky373께서 투자하신 시간과 노력이 좀 아까운 것 같습니다. pull_request_target을 통해서 해결이 가능한 문제라면 해결해보시는 것도 나쁘지 않을 것 같습니다. 레이블 추가해주는 깃허브의 공식 액션 actions/labeler도 pull_request_target을 사용하라는 것으로 봐서 흔히 사용되는 패턴인 것 같습니다.

맨 처음에 건의 주셨을 때 말씀드렸어야 했던 것 같은데, 저도 이렇게 노이즈가 많이 발생할 줄은 몰랐네요. 제가 검토하고 승인한 PR인데 저의 불찰도 큽니다.

[sounmind]

@bbFactory 님이 이렇게 고생하고 계신 줄 몰랐네요. 상세한 리포트 감사합니다! 잘 읽었습니다.
@DaleSeo 님이 말씀하신 대로, Labeling 자동화에 너무 많은 시간을 쏟으셔서 오히려 의욕이 저하될 수도 있을 것 같아 걱정이기도 합니다.

혹시 문제를 해결하는데 도움이 될까 싶어, 달레님이 말씀해주신 actions/labeler를 이전 회사에서도 사용했던 경험이 있어서, 간단하게 깃허브 액션을 만들어봤습니다. 제 개인 레포지스토리에서는 잘 작동하지만 이 이슈의 중점이었던 fork 레포에서의 변경사항에도 잘 적용될지는 모르겠습니다. 바로바로 확인할 수가 없네요. 정기 미팅 시간 뒤에 시간이 좀 남는다면 같이 실험해볼 수도 있겠네요!