정적 사이트(static site)를 하나 만들고 나면 어디에 올릴지부터 고민하게 되는데요. GitHub Pages는 간편하지만 PR마다 변경 사항을 미리 열어 볼 주소를 띄우기 어렵고, 리디렉션이나 응답 헤더를 마음대로 바꿀 수도 없습니다. 🤔 Cloudflare Pages는 GitHub 저장소를 연결해 두면 푸시할 때마다 알아서 빌드하고 Cloudflare의 전 세계 네트워크에 배포해 주는 서비스입니다. 운영 브랜치가 아닌 브랜치에 푸시하면 따로 설정하지 않아도 프리뷰 배포(preview deployment)가 만들어지고, 무
오픈소스를 운영하다 보면 스타가 늘거나 이슈가 쌓이는 일에는 어느새 익숙해지는데요. 그러던 어느 날 저장소 Security and quality 탭에 처음 보는 빨간 알림이 뜨고 "당신의 패키지에서 보안 취약점을 발견했습니다"라는 제보가 들어오면 이야기가 달라집니다. 머릿속이 하얗게 변하면서 "이걸 이슈로 답해야 하나? 일단 코드부터 고쳐서 푸시할까?" 하는 생각이 먼저 떠오르죠. 😅 이건 결코 남의 일이 아닌데요. 2021년 전 세계 서버를 떨게 한 Log4j의 Log4Shell 같은 대형 사건도 있었지만, 멀리 갈 것도 없이
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 GitHub Pages로 웹사이트를 호스팅할 수 있다고 배웠는데요. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다. 이번 포스팅에서는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대
GitHub Pages로 웹사이트 무료 호스팅하기에서 살펴봤듯이, GitHub Pages에 웹사이트를 배포하면 기본적으로 github.io 서브 도메인을 무료로 제공해주는데요. 대부분의 개인 프로젝트에서는 GitHub Pages의 기본 도메인을 사용해도 큰 지장이 없을 것입니다. 하지만 비즈니스를 위한 웹사이트를 호스팅할 때는 브랜딩이나 SEO(검색 엔진 최적화) 차원에서 커스텀 도메인을 원하게 되죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 배포한 웹사이트에 커스텀 도메인을 연결하는 방법을 알려드리겠습니다.
GitHub Pages는 깃허브에서 코드 저장소에 딸려오는 무료 호스팅 서비스입니다. GitHub Pages를 사용하면 정적 웹사이트, 블로그, 포트폴리오, 프로젝트 문서 등을 아주 손쉽게 웹에 배포할 수 있죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 웹사이트를 배포하는 가장 기초적인 방법을 알려드리겠습니다. GitHub Pages란? GitHub Pages는 깃허브 저장소에 올려놓은 프로젝트를 최소한의 노력으로 웹에 호스팅해주는 서비스입니다. 깃허브에서 거의 초창기부터 무료로 제공하고 있는데 은근히 모르시
오픈소스 프로젝트를 운영하다 보면 코드 기여자에게만 공을 돌리기 쉽습니다. 하지만 문서 작성, 번역, 버그 리포트, 디자인, 아이디어 제안 등 다양한 방식으로 프로젝트에 기여하는 분들도 많죠. 이런 다양한 기여자들을 빠짐없이 인정해주고 싶은데, 어떻게 해야 할까요? 🤔 이번 포스팅에서는 All Contributors라는 도구를 소개해드리려고 합니다. All Contributors는 코드 기여뿐만 아니라 모든 형태의 기여를 인정하자는 철학을 담은 명세(specification)이자, 이를 자동화해주는 봇과 CLI 도구입니다. All
블로그를 운영하다 보면 독자와 소통하고 싶다는 생각이 들 때가 있습니다. 글에 대한 피드백을 받기도 하고 궁금한 점을 질문으로 남겨주시는 분도 계시죠. 때로는 본문보다 댓글에서 더 좋은 방법을 알게 되기도 하고요. 문제는 정적 블로그에 댓글 기능을 붙이려면 별도 서버나 데이터베이스가 필요하다는 겁니다. Disqus 같은 서비스를 쓸 수도 있지만 광고가 붙고 사용자 추적도 신경 쓰이고요. 이럴 때 쓸 만한 도구가 Giscus입니다. GitHub Discussions를 댓글 저장소로 쓰는 오픈소스 프로젝트인데요, 별도 서버 없이 댓글
깃허브(GitHub)는 개발자들이 소프트웨어 프로젝트를 관리하고 협업하는 데 필요한 다양한 기능을 제공하는 매우 인기있는 플랫폼인데요. 일상적인 개발을 할 때는 깃허브의 웹사이트를 통해서 대부분의 작업을 처리할 수 있지만 개발 과정을 자동화하거나 다른 개발 도구와 통합할 때는 프로그래밍적으로 접근해야 할 때가 있습니다. 이럴 때는 깃허브에서 제공하는 REST API를 사용하면 되는데요. 이번 포스팅에서는 터미널에서 curl로 깃허브의 REST API를 실제로 같이 호출해보면서 기본적인 API 사용 방법에 대해서 알아보겠습니다. 터미
새 프로젝트에 합류했는데 개발 환경 설정에만 하루 이상 걸린 적 있으신가요? Node.js 버전이 안 맞고, Python 패키지가 충돌하고, 데이터베이스 설치가 안 되고… 😅 이런 문제는 개발자라면 누구나 한 번쯤 겪어봤을 텐데요. Dev Container는 이런 골치 아픈 개발 환경 설정을 컨테이너 안에 통째로 담아서 해결합니다. 설정 파일 하나만 프로젝트에 넣어두면 팀원 누구나 동일한 환경에서 바로 작업을 시작할 수 있죠. 이번 글에서는 Dev Container가 뭔지, 어떻게 쓰는지 처음부터 차근차근 알아보겠습니다. Dev
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)를 하나를 만들고 시작하겠습니