day-log

오늘 삽질하다가 알게 된 건데, cancel-in-progress: true 이거 그냥 다 켜두면 안 된다. 우리 팀에서도 몇 달 전에 이거 때문에 한 번 크게 데었다. PR 워크플로우에서는 문제 없이 잘 돌던 설정을 main 브랜치 배포 워크플로우에까지 그대로 붙여놨더니, 연달아 커밋이 두 번 들어왔을 때 앞선 배포가 중간에 잘려버리고 뒤 커밋만 배포됐다. 그 사이에 이미 헬름 릴리즈는 1단계까지 올라가 있었고. 정확히는 ArgoCD sync가 반쪽만 돈 상태였는데, 이걸 새벽에 알림 보고 복구하느라 한참 걸렸다.group 스코프를 어디로 잡을지가 핵심기본 패턴은 이거다.concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-p..

오늘 알게 된 건데, GitHub Actions에 queue: max 옵션이 생겼다. 5월 초에 조용히 릴리즈된 것 같다. 이거 모르는 분 꽤 많을 것 같아서 짧게 정리한다.기존 방식의 아쉬움우리 팀은 배포 파이프라인에 concurrency 그룹을 걸어 놨었다. 같은 환경에 두 개가 동시에 배포되면 곤란하니까.concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false문제는 이 설정으로 큐잉되는 최대 개수가 딱 1개였다는 거다. 진행 중 1개 + 대기 중 1개, 총 2개까지만. 세 번째 잡이 들어오면 대기 중이던 잡이 그냥 취소됐다. 배포 트리거가 몰리는 날에는 중간 잡이 스킵돼 버려서, PR 머지 순서움 실제 배포 순서가 어긋나는 상..

이거 모르는 분 꽤 많더라. 우리 팀도 작년 말까지 모르고 있었고, 우연히 디플로이 파이프라인 디버깅하다가 발견했다.concurrency: 블록을 workflow 레벨에 걸어 둔 상태에서 matrix strategy로 OS 3개를 동시에 돌리면 어떻게 될까. 정답은 3개가 서로를 취소시킨다.name: teston: [push]concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: truejobs: test: strategy: matrix: os: [ubuntu-latest, macos-latest, windows-latest] runs-on: ${{ matrix.os }} ..

오늘 알게 된 건 아니고, 어제 팀 PR 리뷰하다가 "어 이거 아직도 모르는 분들 꽤 많은데" 싶어서 짧게 정리해둔다. 우리 팀에서도 작년 한 분기 동안 같은 사고를 두 번 냈다. 똑같은 워크플로가 동시에 두 개 뜨면서 한쪽이 helm release를 절반쯤 적용한 상태에서 다른 한쪽이 덮어쓰는 그림. 새벽 3시에 슬랙 알림으로 깨면 진짜 멘탈이 묘하게 무너진다.한 줄이면 끝난다concurrency: group: deploy-${{ github.ref }} cancel-in-progress: false이게 전부다. 같은 브랜치에서 deploy 워크플로가 한 번에 하나만 돌게 만든다. PR 빌드용 워크플로면 cancel-in-progress: true로 바꿔서 새 커밋이 들어올 때 진행 중인 빌드를 죽..