day-log

지난주 화요일 새벽 3시 반쯤, 슬랙 알림에 깼다. "CI 전체 실패 중" 이라는 온콜 메시지. 눈 비비고 노트북 열었더니 GitHub Actions 화면이 온통 빨간색이었다. 로그를 열어보니 다들 같은 메시지를 뱉고 있었다.No space left on device우리 팀은 self-hosted runner를 EC2 위에 올려서 쓴다. 처음 세팅했을 때부터 "언젠가 디스크 문제 터진다"는 거 알고 있었는데, 대응을 미루다가 결국 새벽에 얻어맞은 케이스였다. 그날 겪은 삽질을 정리해둔다.상황우리 러너 구성은 대략 이랬다.c6i.2xlarge EC2 3대, ephemeral 아니고 long-runninggp3 100GB 루트 볼륨 하나Docker in Docker로 이미지 빌드/테스트하루 평균 400개 정..

CI에서 Docker 빌드 시간이 아깝다는 얘기를 최근에도 팀에서 몇 번 들었다. 로컬에선 5초 만에 끝나는데 GitHub Actions에서만 3분씩 걸리는, 그 짜증나는 상황. 오늘 알게 된 건 아니지만 의외로 모르는 분들 꽤 많더라. 짧게 정리해둔다.문제는 러너가 매번 새거라는 점BuildKit의 RUN --mount=type=cache는 원래 로컬에서 잘 돈다. 예를 들면 이런 식.# syntax=docker/dockerfile:1.7FROM node:20WORKDIR /appCOPY package*.json ./RUN --mount=type=cache,target=/root/.npm \ npm ciCOPY . .RUN --mount=type=cache,target=/app/node_modul..

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

재사용 워크플로우(reusable workflow) 쓰다 보면 거의 반사적으로 secrets: inherit 한 줄 박아두게 된다. 편하니까. 근데 이게 동작 방식을 정확히 모르고 쓰면 디버깅하다가 한 시간씩 날려먹는 포인트가 몇 개 있다. 오늘은 그 중 자주 걸리는 것들만 짧게 정리.inherit는 "직접 호출한 워크플로우"까지만 간다체인 호출에서 제일 많이 헷갈리는 부분이다. A → B → C 구조라고 하자. A에서 B를 부르면서 secrets: inherit을 줬다. B에서 C를 부르는데 거기에 secrets: inherit을 또 안 적으면, C는 시크릿을 못 본다. inherit는 한 단계만 전파된다.# A.ymljobs: call-b: uses: ./.github/workflows/B.y..

Access Key를 GitHub Secrets에 박아두는 거, 이제 진짜 그만할 때가 됐다. 우리 팀도 작년에 한 번 키가 외부로 새서 식겁한 적이 있는데, 그 사건 이후로 모든 리포지토리를 OIDC로 옮겼다. 사실 옮기는 작업 자체가 어렵진 않다. 어려운 건 신뢰 정책(trust policy)을 너무 느슨하게 잡거나, 반대로 너무 빡빡하게 잡아서 워크플로우가 자꾸 깨지는 거다.이번 글에선 GitHub Actions의 OIDC 토큰으로 AWS IAM Role을 assume하는 과정을 실전 기준으로 정리한다. 처음 세팅하는 사람도 따라할 수 있게 단계별로 적었다.왜 OIDC인가장기 credential(Access Key/Secret Key)을 Secrets에 저장하면 두 가지가 걸린다. 하나는 키가 유출..

이거 모르는 분 꽤 많더라. 우리 팀도 작년 말까지 모르고 있었고, 우연히 디플로이 파이프라인 디버깅하다가 발견했다.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 }} ..

이번 주에 우리 팀 IAM trust policy 점검하다가 좀 놀란 게 있어서 짧게 적어둔다. 이거 모르는 분 꽤 많을 것 같다.익숙한 그 패턴GitHub Actions에서 AWS 붙일 때 OIDC federation 쓰는 건 이제 거의 표준이다. 그런데 trust policy 보다 보면 이런 게 자주 나온다.{ "Condition": { "StringLike": { "token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*" } }}좋다, 우리 repo로 한정은 했다. 근데 *이 너무 넓다. PR에서 돌아가는 워크플로우든, 누가 임시로 만든 브랜치에서 돌리는 거든, 환경 보호 없는 워크플로우든 — 전부 이 role을 가..

작년 봄에 우리 팀 CI/CD 표준을 정리하면서 GitHub Actions의 Reusable Workflow와 Composite Action을 둘 다 도입했다. 그땐 "쓰임새가 다르니까 둘 다 쓰자"가 결론이었는데, 1년 굴려보니 둘의 경계가 처음 생각보다 훨씬 명확하게 갈렸다. 그리고 최근 GitHub이 2026 Actions 보안 로드맵을 발표하면서 Composite action의 nested dependency 노출 방식, scoped secrets 같은 변경이 들어오기 시작해서, 이참에 한번 정리해두면 좋을 것 같다.이 글은 단순히 둘의 문법 차이를 비교하는 글은 아니다. 실제로 우리 팀이 어떤 기준으로 갈라 썼고, 어디서 후회했고, 지금 어떻게 운영하는지에 대한 회고에 가깝다.단도직입적으로, 우..