PR 던진 후 github action 동작 시 secret_key 에러

이에 대해 자료를 조사하던 중 동일한 현상을 겪는 분의 글을 찾아 공유한다.
https://leeeeeyeon-dev.tistory.com/32 ( 감사합니다 :) )

위 글에 따르면 현재 나와 동일한 문제를 겪고 있다. 프로젝트에 참여하기 위해 우아한 형제들에서 사용하는 git flow 전략을 따르려 했고, repo를 fork 받은 후에 나의 origin repo에서 작업하고 모든 작업을 commit한 후 upstream으로 PR을 송신하여 새로운 코드를 적용하는 식으로 업무를 수행하려 하였다.

프로젝트에 새로운 기능을 구현한 후 추가해야하는 상황에서 프로젝트 참여 초기 PR 송신 후 github action 파이프라인이 동작할 때 정상적으로 통과하지 못하는 문제가 발생하였다.

분명 다른 분들이랑 동일한 방식을 채택하여 PR을 송신하였는데(사실 크게 다를 것도 없다), 왜 정상적으로 CI/CD 파이프라인이 통과되질 않는걸까?

이 글을 작성하고 있는 지금 사진을 첨부하고 싶었지만, 시간이 좀 흐른 뒤라 로그가 삭제되었다고 하지만, 로그를 확인해봤을 때, github action의 secret key들이 ***과 같은 형식으로 출력되는 것이 아닌, 아무것도 출력되지 않는 현상을 발견하였다.

왜 이런 현상이 발생하는지 구글링을 좀 해보니, fork 뜬 레포에서 pr을 던지면 무조건 GITHUB_TOKEN 권한이 없는 상태로 주어져서(공문 참고) secrets를 읽어오질 못한다는 내용의 글을 찾을 수 있었다.

그럼 어떻게 이 문제를 해결할 수 있을까? 알아본 바에 따르면 약 3가지 정도로 추릴 수 있을 것 같다.

1. yaml 파일에 permissions 키를 추가
이 방법은 사용해보진 않았고 시도도 해보지 않았지만, permission을 제공해야한다는 점에서부터 이미 보안 상 안전하지 않을 것 같은 냄새가 풀풀 풍겨 바로 기각하였다.

2. pull_request_target event로 PR을 송신
생각보다 이러한 문제를 겪는 사람들이 있어 github에서 추가한 새로운 event인 것으로 보인다. 공문을 읽어보면 fork후 PR을 송신하면 기본적으로 read-only의 권한과 secret에 대한 접근은 제한된 권한이 주어진 상태로 송신된다는 것 같은데, 요즘 github action으로 단순 CI/CD만 제공하기 위해 사용하는 분위기는 아니기 때문에 좀 더 유연한 확장을 위해 이러한 event를 만든 것이라고 한다.
그러나 이 방식 역시 따로 신뢰할 수 있는 출처로부터 온 PR인지 확인하는 과정이 필요하다고 적혀있기 때문에 이 방식 역시 괜히 일을 만드는 느낌이라 기각하였다.

3. 그냥 UpStream repository를 그대로 clone
사실 이 방식이 가장 단순하고 편한 방식이다. 그러나, 좀 더 우아하게 해결할 수 있는 방식이 있을 줄 알고 열심히 구글링하였으나, 가장 납득이 가능한 방식이 해당 방식이라고 결론 지었고, 무엇보다 글 상단에 있는 블로거 분의 의견에 따라 해당 방식을 채택하는 것이 현업에서 자주 사용하는 방식이며, fork받아 프로젝트에 기여하는 형식은 오픈소스에서 자주 나타나는 모습이라는 글을 읽고 해당 방식을 채택하기로 하였다.

아래는 내가 기존에 사용하던 방식이고 그 다음 사진이 납득 가능한 수준에서 github action을 PR마다 적용할 수 있는 변경된 방식이다. 참고하여 다른 분들은 혼란이 없었으면 한다.

기존에 사용하던 전략과 수정한 전략