[Github] Github actions to Slack 자동화

자동화 어디까지 해봤니?

때는 바야흐로 1년 6개월 전...

팀에서 feature -> develop -> release -> release 슬랙에 공지하면서 동시에 빌드 넘버, 버전 넘버를 함께 제공해서 팀 공지방에 알려주고 있었다.

아..

이 얼마나 괴로운가...
많은 것들이 release 브랜치에 탑승하고 이륙하고 탑승하고 이륙하고 할 때마다 계속
git rev-list HEAD --count 명령어를 통해 빌드 넘버와 버전 정보를 함께 제공해야 했다.

바쁠 때 이 액션을 신경 못쓰면 QA를 기다리는 자와 빨리 다른 버그를 고쳐야하는 둘 다 개고생하게 된다.
내가 그랬으니까...

그래서 팀적으로 여유가 좀 생겼을 때 이 액션을 자동화 해야겠다고 마음을 먹고 아래와 같은 슬랙 채널을 만들었고 슬슬 시동을 걸었다.

자 23년 12월7일에 만들었는데 왜 지금 포스팅하냐? 사연이 있었습니다......

💡 1차 시도 (with.Circle CI)

1차 시도는 회사에서 사용하는 Circle CI를 사용했다.

결론부터 말하면 실패에 가깝다. 왜냐 pull_request의 title body를 가져와야하는데 title은 제대로 가져와 지는데 body 부분을 썡 string으로 가져와지는 대참사가 일어났다..

이게 왜 대참사 ?

팀의 컨벤션은

• (#123) 화면 개발
• (#124) 화면 디자인 수정
• (#125) 화면 QA

이런식으로 가져와야하는데 \n이 도통 먹질 않았다.
코드를 살펴봤을 때 개행하는 부분을 작업할 시기 latest에 안되게 수정을 해놨다 뭐지...?
그래서 Circle-CI의 slack-orb에 이슈로 제보하게 되었다.
slack-orb multiline issue

담당자로 보이는 분과 여럿 소통을 했지만 수정해서 나온다 기다려달라 라는 답변만 받은채 끝난 일방적 소통..

결국 Circle-CI로 하는 건 포기했다. 왜냐 슬슬 바빠지기도 했고 다음을 기약하게 되었다.

💡 2차 시도 (with.Github Actions)

개인 사이드 프로젝트를 하면서 github action을 통해 commit push를 하면 lint를 돌리는 소소한 자동화를 해본 경험이 있고
마침 딱 2일 정도의 시간이 있어서 이번엔 깃헙 액션을 통해 시도 하기로 했다.

저렇게 슬랙 봇을 만드는 과정은 다른 블로그를 보거나 구글링 하는 걸 추천한다.

일단 저번에 만들어둔 incoming webhook에서 테스트 할 슬랙 채널의 webhook url을 받아온다

아 저거 이름 바꿔야하는데 사랑해요 github actions😇

이제부터 자세히 들어갑니다요

1. 어떤 상황에서 자동화를 하고 싶니 ?

난 release branch가 닫혔을 때 액션을 돌리고 싶었다.

on: 
  pull_request:
    types: [closed]
    branches:
      - release/*

본문을 보면 pull_request의 타입이 closed여야하고 branch는 release/로 시작하는 브랜치에서 실행한다는 설정 걸어준다.

주의사항 !

난 pull_request의 title과 body 내용을 가져오고 싶었지만 할떄마다 pull request를 생성해서 하기가 너무 귀찮고 팀 슬랙에 노이즈도 많이 생겨서 -feature/*로 했다.

on: 
  pull:
    branches:
      - release/*
      - feature/*

하지만 pull request의 정보를 가져오려면 pull로는 안된다... pull reqeust로 설정을 하고 액션을 돌려야 로그에 제대로 남는다.

조심 !

2. 무엇을 자동화 하고 싶니 ?

1. 일단 pull_request를 가져온다.
2. pull_request의 객체 중 내가 원하는걸 고른다 (ex. title, body.....)

크게 2가지이다.

그럼 먼저 pr_title을 가져와보자.

jobs:
  notify: # 이 부분은 작업(job)의 이름을 정의합니다.
    runs-on: ubuntu-latest  # 작업이 실행될 환경을 정의합니다. 여기서는 최신 우분투 이미지를 사용합니다.
    
    steps:  # 각 작업 내에서 실행할 단계(steps)를 정의합니다.
      - name: Checkout code  # 단계의 이름을 정의합니다.
        uses: actions/checkout@v3  # 코드를 체크아웃하기 위해 GitHub 제공 액션을 사용합니다.
        with:
          fetch-depth: 0  # 전체 히스토리를 가져옵니다.
        
     - name: Get Pull Request details  # PR 세부 정보를 가져오는 단계
        id: pr_details  # 이 단계의 ID를 정의합니다. 나중에 참조할 수 있습니다.
        run: |
          echo "PR_TITLE=${{ github.event.pull_request.title }}" >> $GITHUB_ENV
     - name: Get commit count and version
     	id: commit_details
        run: |
          git fetch --all
          COMMIT_COUNT=$(git rev-list HEAD --count)
          echo "COMMIT_COUNT=$COMMIT_COUNT" >> $GITHUB_ENV

스킵한 부분은 주석을 읽어주세요 !

steps 1. Get Pull Request details

github PR에서 날아온 데이터 중 title을 가져와서 PR_TITLE에 할당하고 ENV 값으로 넣는다는 뜻이다.

steps 2. Get commit count and version

commit count를 가져오는 곳이다.

처음 생각했을 때 예를 들어 release/28.12라고 해보자 어? 그럼 어떻게 뒤에 숫자를 특정해서 해당 release 브랜치로 이동하지? 했는데 생각해보니 이건 최신 release에서만 돌잖아...? 라는 생각과 머리를 탁치며 git fetch만 해온 뒤 우리의 버전 넘버에 필요한 커밋 카운트만 계산하기로 했다.
머쓱ㅋㅋ.....

3. 어떻게 보내고 싶니 ?

자 이제 보낼 데이터는 다 가공했다.

이제 제가 제일 힘들었던 순간이 나옵니다

      - name: Send notification to Slack
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          PR_TITLE: ${{ env.PR_TITLE }}
          COMMIT_COUNT: ${{ env.COMMIT_COUNT }}

        run: |
          curl -X POST -H 'Content-type: application/json' \
          --data "{\"text\":\"*앱 ${PR_TITLE} (build 51${COMMIT_COUNT})의 내부테스트가 곧 가능합니다*\"}" \
          $SLACK_WEBHOOK_URL

1번, 2번 스텝에서 정의 했던 PR_TITLE값과 COMMIT_COUNT를 ENV에서 가져오고
secrets.SLACK_WEBHOOK_URL을 가져온다. 어떻게 가져오냐 ?

github -> settings -> secrets and variables -> Actions -> Repository secrets
에 New repository secret 버튼을 눌러서 만들 수 있다.

그럼 이제 run에서 내가 보낼 내용에 맞게 보낼 준비를 한다.

run 코드에선 slack api webhook에 나와있는 예제대로 보내줘야 한다.

만약 아직 슬랙 채널을 만들지 않았다면 위 사진이 보이는 페이지 하단에

Add New Webhook to Workspace에서 채널 리스트를 선택하고 만들면 url과 채널명이 나온다.

그럼 이제 pull_reqeuset로 설정했으니 pr을 merge 하면 ?!

💡 결과 !

---

이렇게 잘 나온다.

만약 슬랙에 메세지를 보낼 때 invalid_payload라는 에러가 뜰 수도 있는데 그건 보내는 메세지 내용이 뭔가 잘못됐다고 하는거니 따옴표, 큰 따옴표를 자세히 살펴보자..
만약 값이 안들어온거면 그 값을 제외간 다른 것들만 나오니 참고 !

💡 회고

1년 반이라는 시간이 걸렸다.
하면서 아쉬웠던 점은 이 자동화를 원하는 사람들의 니즈를 먼저 들어보고 시작했으면 좀 더 좋지 않았을까? 이다.
pr body 값이 제대로 들어오지 않을 떄 개발팀 하루 마무리 커피챗 때 얘기했다.

🙋🏻‍♂️ : 다른 건 다 잘들어오는데 body가 개행이 되지 않고 한줄로 들어옵니다.. 이걸 어떡하죠?
💁🏻‍♂️ : 빌드넘버와 커밋카운트만 오더라도 너무 좋을 것 같아요 ㅠㅠ 그거 매번 하기 너무 힘들고 귀찮았거든요 !

어라...? 처음부터 너무 완벽하게 될 모습을 상상하고 작업을 시작한게 큰 패착이었다.
정신적 리소스를 너무 낭비한 느낌...

결국 내 욕심으로 인해 pr title, body, version tag, commit count 등등 전부 다 한번에 가져오려는게 욕심이었다. 작업의 난이도를 낮추는 법을 팀에서 항상 연습하고 배웠는데도 막상 작업 앞에 가면 큰 산을 마주한 느낌이 들 때가 종종 있다. 그래도 이번엔 좀 수월하게 됐지만 더 연습이 필요한 것 같다. 화이팅 !

+뿌듯한 점 ㅎㅎ...
매번 귀찮았던 작업을 자동화를 했고 이로 인해 나도 그렇고 개발팀도 그렇고 조금이라도 리소스를 아낄 수 있을 것 같다는 생각에 신이 난다.

물론 주말에 카페 나와서 약속 시간전까지 작업을 오랜만에 하는 것도 묘하게 신이 난다. (맥북 너무 무거움 주의)

암튼 작업도 잘 끝났고 이제 약속도 갈 시간이니 블로그는 여기서 끝 !