Rust로 라이브러리를 만들어서 crates.io에 배포하고 있다면 릴리스할 때마다 반복해야 하는 작업이 꽤 많다는 걸 느끼셨을 거예요. Cargo.toml의 버전 올리고 체인지로그 정리하고 cargo publish 실행하고 git 태그 만들고 GitHub Release도 작성하고... 🤔 매번 수작업으로 하다 보면 빼먹는 단계가 생기기 마련이죠. release-plz는 이 과정을 통째로 자동화해주는 도구인데요. Conventional Commits 기반으로 버전을 알아서 올려주고, 체인지로그도 자동 생성하고, PR 하나 머지하면
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)은 어떤 이벤트가 발생했을 때 독립된 환경에서 실행되야 하는
우리가 코드를 관리하는 GitHub의 저장소(repository)에서는 여러가지 일(event)들이 일어날 수 있죠? 개발자가 새로운 커밋(commit)을 푸시(push)할 수도 있고, 기여자(contributor)가 PR(pull request)을 제출하거나 사용자가 이슈(issue)를 보고할 수도 있습니다. GitHub Actions를 사용하면 이렇게 GitHub 저장소에서 일어나는 다양한 이벤트에 자동으로 반응하도록 워크플로우(workflow)를 구성할 수 있는데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우를
지난 포스팅에서는 GitHub Actions를 이해하기 위해서 필요한 핵심 개념에 대해서 알아보았습니다. 이번 포스팅에서는 GitHub Actions 입문자를 위해서 정말 기초적인 워크플로우를 하나 생성해보려고 함께 테스트를 해보겠습니다. GitHub 저장소 생성 GitHub 계정이 있으시다면 누구나 무료로 GitHub 워크플로우를 사용해볼 수 있습니다 🤗 실습을 위해서 본인 GitHub에 계정에 github-actions-first-workflow라는 이름으로 새로운 코드 저장소(repository)를 하나를 만들고 시작하겠습니
GitHub가 Microsoft에 인수된 이후 야심차게 출시한 GitHub Actions는 CI/CD 시장에 지각변동을 일으키고 있는데요. 전 세계에 대부분의 개발자들이 이미 깃허브 계정이 있다고 해도 과언이 아닌 유리한 상황에서, GitHub Actions의 약진은 Jenkins, Circle CI, Travis CI와 같은 기존에 유수의 서비스까지도 위협하고 있습니다. 이번 포스팅은 제 블로그에서 GitHub Actions에 대해서 처음 다루는 만큼 GitHub Actions를 처음 접하시는 분들을 위해서 아주 얇고 넓게 Git