회사에서 Rust로 만든 오픈소스 애플리케이션을 하나 관리하고 있는데요. 라이브러리가 아니라 실행 파일이라서 그동안 바이너리와 Docker 이미지로만 배포해 왔어요. 그런데 어느 날 이런 이슈가 올라왔습니다. 많은 회사가 규정상 crates.io 미러에 있는 패키지만 받아서 소스로 빌드해야 합니다. git 소스로만 공개된 패키지는 아예 쓸 수가 없어요. 생각해 보니 맞는 말이었습니다. 보안 규정이 엄격한 조직일수록 외부 바이너리를 그대로 들이지 않고 사내 레지스트리(registry)에 미러링한 크레이트(crate)만 빌드에 쓰게 하
워크플로우를 처음 만들 때는 API 키 하나쯤 YAML 파일에 그냥 적어 두고 싶은 유혹이 생기는데요. 저장소가 공개되어 있다면 그 순간 키는 전 세계에 공개된 셈이죠. 😅 그렇다고 모든 설정값을 꽁꽁 숨기자니, 앱 이름이나 로그 레벨처럼 굳이 감출 필요가 없는 값까지 로그에서 ***로 보여서 디버깅이 괴로워집니다. GitHub Actions는 그래서 설정값을 두 종류로 나눠 보관합니다. 민감한 값을 담는 시크릿(secret)과, 감출 필요는 없지만 코드 밖으로 빼고 싶은 값을 담는 변수(variable)예요. 이번 글에서는 둘의
Cloudflare Workers로 만든 서비스가 하나둘 늘어나면 wrangler deploy를 직접 치는 게 슬슬 부담스러워지는데요. 누가 언제 어떤 커밋을 배포했는지 기록도 남지 않고, 테스트를 깜빡하고 배포하는 날도 생깁니다. 😅 결국 GitHub에 푸시하면 알아서 배포되는 흐름이 필요해집니다. Workers를 GitHub와 연결하는 방법은 크게 두 가지입니다. 하나는 Cloudflare가 직접 빌드와 배포를 맡는 Workers Builds이고, 다른 하나는 GitHub Actions 워크플로우에서 Wrangler를 실행하는
GitHub Actions로 저장소를 자동화하다 보면 어느 순간 벽에 부딪힙니다. 새 이슈가 열릴 때 알맞은 라벨을 붙여주고 싶은데, 그 규칙을 조건문으로 적으려니 답이 안 나오는 거죠. 제목에 "버그"가 들어가면 bug 라벨을 붙이자고 시작하지만, 정작 사용자가 올리는 이슈는 "로그인하면 화면이 하얘져요" 같은 문장이거든요. 😅 이런 일은 규칙이 아니라 판단이 필요한 작업입니다. 이슈를 읽고, 무슨 말인지 이해하고, 빠진 정보가 무엇인지 알아채야 하니까요. 사람이 하기엔 지루하고 기계가 하기엔 애매한, 딱 그 사이에 있는 일이죠
npm에서 라이브러리를 하나 고를 때 무엇을 보시나요? 저는 스타 수만 보고 정하지는 않습니다. 저장소에 들어가서 이슈에 답이 잘 달리는지, 릴리스가 꾸준한지, 기여자가 몇 명이나 되는지를 훑어보죠. 그런데 그렇게 살펴봐도 손에 남는 건 "괜찮아 보인다"는 인상뿐입니다. 왜 이걸 골랐냐고 누가 물으면 딱 떨어지는 근거를 대기가 어렵고, node_modules에 딸려 들어온 수백 개의 간접 의존성을 하나하나 같은 눈으로 볼 수도 없고요. 눈으로 하는 판단은 저 혼자 쓰고 끝나는 데다, 개수가 늘어나면 금방 감당이 안 됩니다. 게다가
GitHub Actions로 배포나 테스트를 자동화하다 보면 API 키, 데이터베이스 비밀번호, 배포 토큰 같은 시크릿을 다루게 됩니다. 처음에는 GitHub Secrets에 하나씩 넣어두면 충분해 보이는데요. 프로젝트가 늘어나고, 시크릿을 여러 저장소에서 공유하고, 키를 주기적으로 교체해야 하는 순간부터 관리가 조금씩 복잡해집니다. 이럴 때 1Password를 시크릿의 원천 저장소로 두고, GitHub Actions에서는 실행 시점에 필요한 값만 읽어오게 만들 수 있습니다. GitHub에는 1Password에 접근하기 위한 서비스
GitHub Actions는 무료로 시작할 수 있고 워크플로우 한두 줄이면 배포까지 굴러가니 정말 편하죠. 그런데 편한 만큼 위험도 가까이에 있는데요. 워크플로우 한 줄을 잘못 쓰면 저장소의 모든 비밀이 외부로 흘러나가거나, 누군가의 PR 제목이 곧바로 러너에서 셸 명령으로 실행되는 일도 일어납니다. 실제로 PR 제목에 백틱과 셸 명령을 끼워 넣어 러너의 환경 변수와 토큰을 탈취한 사례가 종종 보고되고 있고, 인기 액션의 메인 브랜치가 손상되어 수많은 저장소에서 비밀이 유출되는 사고도 잊을 만하면 한 번씩 터집니다. 다행히 깃허브가
클로드 코드를 터미널에서 사용하는 것도 좋지만, GitHub 저장소에 통합해서 팀 전체가 활용할 수 있다면 어떨까요? PR을 올릴 때마다 Claude가 자동으로 코드를 리뷰하고, 이슈에 @claude를 태그하면 자동으로 수정 PR을 만들어주고, 심지어 매일 밤 자동으로 코드베이스 리포트를 생성할 수도 있습니다. 바로 클로드 코드 GitHub Actions가 가능하게 하는 일들이죠. 이번 글에서는 클로드 코드를 GitHub Actions와 통합해서 AI 기반 워크플로우를 자동화하는 방법을 알아보겠습니다. 클로드 코드 GitHub Ac
Rust로 라이브러리를 만들어서 crates.io에 배포하고 있다면 릴리스할 때마다 반복해야 하는 작업이 꽤 많다는 걸 느끼셨을 거예요. Cargo.toml의 버전 올리고 체인지로그 정리하고 cargo publish 실행하고 git 태그 만들고 GitHub Release도 작성하고... 🤔 매번 수작업으로 하다 보면 빼먹는 단계가 생기기 마련이죠. release-plz는 이 과정을 통째로 자동화해주는 도구인데요. Conventional Commits 기반으로 버전을 알아서 올려주고, 체인지로그도 자동 생성하고, PR 하나 머지하면
정적 사이트(static site)를 하나 만들고 나면 어디에 올릴지부터 고민하게 되는데요. GitHub Pages는 간편하지만 PR마다 변경 사항을 미리 열어 볼 주소를 띄우기 어렵고, 리디렉션이나 응답 헤더를 마음대로 바꿀 수도 없습니다. 🤔 Cloudflare Pages는 GitHub 저장소를 연결해 두면 푸시할 때마다 알아서 빌드하고 Cloudflare의 전 세계 네트워크에 배포해 주는 서비스입니다. 운영 브랜치가 아닌 브랜치에 푸시하면 따로 설정하지 않아도 프리뷰 배포(preview deployment)가 만들어지고, 무
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 GitHub Pages로 웹사이트를 호스팅할 수 있다고 배웠는데요. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다. 이번 포스팅에서는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대
GitHub Actions을 사용하다 보면 시간이 지남에 따라 워크플로우가 점점 복잡해지고, 그에 따라 중복되는 부분이 생기며 결국 워크플로우의 유지보수가 어려워지게 되는데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우를 재사용하여 이러한 중복 설정 문제를 해결해보도록 하겠습니다. 실습 워크플로우 생성 실습을 위해서 자바스크립트 프로젝트의 전형적인 워크플로우 파일을 하나 작성해보았습니다. main 브랜치로 새로운 커밋(commit)이 유입되면 애플리케이션을 빌드하여 배포하는 작업을 수행되도록 하겠습니다. 6개의 단계
많은 분들이 GitHub Actions을 사용하실 때 GitHub Marketplace에 공개된 액션을 사용하실텐데요. 만약에 필요한 액션을 찾지 못했거나 회사에 보안 상의 이유로 승인되지 않은 외부 액션을 사용할 수 없다면 어떻게 해야 할까요? 이번 글에서는 GitHub Actions에서 직접 액션을 만들어보고 워크플로우에서 사용하거나 GitHub Marketplace를 통해 공유하는 방법에 대해서 알아보겠습니다. 액션의 종류 GitHub Actions에서는 도커(Docker) 컨테이너 액션, 자바스크립트 액션, 복합(compos
GitHub Actions 워크플로우를 작성하다 보면 GitHub Pages에 배포하거나, PR에 댓글을 달거나, 이슈에 라벨을 붙이는 등 단순히 코드를 빌드하고 테스트하는 것 이상의 작업을 하게 되는 경우가 많죠? 이때 워크플로우가 GitHub API에 접근하려면 적절한 권한이 필요한데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우의 권한을 제어하는 permissions 키워드에 대해 자세히 알아보겠습니다. GITHUB_TOKEN이란? GitHub Actions에서 워크플로우가 실행될 때마다 GitHub은 자동으로
소프트웨어 개발에서 아티팩트(Artifact)라는 용어는 보통 프로젝트에서 소스 코드를 빌드(build)한 결과물로 생성된 파일을 가리키는데요. 이번 포스팅에서는 GitHub Actions의 아티팩트 기능을 활용하여 깃허브의 CI 서버에 파일을 올리거나 내려받는 방법에 대해서 알아보겠습니다. 실습 프로젝트와 코드 저장소 생성 간단한 실습을 위해서 Create React App을 통해 자바스크립트 프로젝트를 하나 생성하겠습니다. 그 다음 본인 깃허브 계정에 새로운 코드 저장소(repository)를 하나를 만들고 위에서 생성한 프로젝
어느 프로그래밍 언어를 사용하든 요즘 대부분의 소프트웨어 프로젝트는 수많은 다른 패키지에 의존하기 마련인데요. 로컬 환경에서 소프트웨어 개발을 할 때는 이러한 외부 패키지를 최초에 딱 한 번만 설치하면 되지만 항상 새롭게 셋업되는 CI 서버에서는 이 작업을 매번 다시 해야합니다. 이번 포스팅에서는 깃허브에서 제공하는 캐시(Cache) 액션을 사용하여 CI 서버에서 발생할 수 있는 불필요한 패키지 재설치를 예방해보겠습니다. GitHub Actions의 액션(Action)이란? 먼저 GitHub Actions에서 액션(Action)이
이번 포스팅에서는 깃허브의 CI 서비스인 GitHub Actions를 사용하여 자바스크립트 프로젝트의 지속 통합(Continuous Integration)을 위한 워크플로우를 구성하는 방법에 대해서 알아보겠습니다. 또한 자바스크립트 프로젝트에서 GitHub Actions 셋업이 용이하도록 깃허브에서 제공하는 Setup Node 액션에 대해서도 살펴보겠습니다. 실습 프로젝트와 코드 저장소 생성 실습을 위해서 Create React App을 통해 간단한 자바스크립트 프로젝트를 하나 생성하겠습니다. 그 다음 본인 깃허브 계정에 새로운 코
GitHub Actions에서 가장 많이 사용되는 액션(Action)은 무엇일까요? 바로 저장소로 부터 코드를 내려받기 위한 체크아웃(Checkout) 액션인데요. 이번 포스팅에서는 GitHub Actions를 사용할 때 거의 필수적으로 사용하게 되는 체크아웃 액션에 대해서 알아보겠습니다. GitHub Actions의 액션(Action)이란? 먼저 GitHub Actions에서 액션(Action)이 무엇을 의미하는지 간단하게 짚고 넘어가겠습니다. GitHub Actions는 일반적으로 CI(Continuous Integration,
지난 포스팅에서는 GitHub Actions의 4가지 핵심적인 개념인 워크플로우(workflow), 작업(job), 단계(step), 액션(action)에 대해서 가볍게 살펴보았는데요. 이번 포스팅에서는 작업(Job)의 근간이 되는 단계(step)에 대해서 좀 더 깊이 다뤄보도록 하겠습니다. GitHub Actions에서 단계(step)란? GitHub Actions에서 하나의 작업(job)은 순차적으로 실행되는 여러 단계(step)로 모델링이 되는데요. 이 단계는 단순한 커맨드(command)나 스크립트(script)가 될 수도
지난 포스팅에서는 GitHub Actions의 4가지 핵심적인 개념인 워크플로우(workflow), 작업(job), 단계(step), 액션(action)에 대해서 가볍게 살펴보았는데요. 이번 포스팅에서는 이 중에서도 가장 다양하게 설정할 수 있는 작업(job)에 대해서 좀 더 깊이 알아보도록 하겠습니다. GitHub Actions에서 작업(job)이란? 먼저 GitHub Actions에서 작업(job)의 역할과 위치에 대해서 간단히 복습을 하고 넘어가겠습니다. 작업(job)은 어떤 이벤트가 발생했을 때 독립된 환경에서 실행되야 하는