서론
Github Pages(깃헙 블로그)는 jekyll을 이용하여 블로그를 호스팅해준다. 다만, jekyll과 완전히 동일하지는 않은데, jekyll에서도 github pages가 자체적으로 허용한 jekyll-plugin만이 적용이 가능하다. jekyll-paginate, jekyll-seo-tag 등의 플러그인들을 기본적으로 포함하고 있다. 자세한 지원 내용은 아래의 링크에서 확인해볼 수 있다.
jekyll-linkpreview에 관한 내용은 여기에서 확인할 수 있다. jekyll-linkpreview와 같이 github pages에서 지원하지 않는 jekyll-plugin을 적용하기 위해서는 이 포스팅에서 소개하는 방법을 따라하면 좋을 것이다.
jekyll-deploy-action
GitHub Pages는 안전 모드에서 실행되며 일부 허용 목록에 있는 플러그인들을 사용한다. 그래서 GitHub Pages에서 gem을 사용하려면 로컬에서 빌드하거나 CI(예: Travis, GitHub Workflow)를 사용하여 gh-pages 브랜치에 배포해야 한다.
따라서, Jekyll 사이트를 로컬에서 실행되는 것처럼 만들고 사용자 정의 플러그인이 제대로 작동하도록 하려면, jekyll-deploy-action을 사용하면 된다.
Github blog 레퍼지토리에서 .github/workflows/build-jekyll.yml을 아래와 같은 내용으로 변경해주면 된다. 단순히 새로운 플러그인을 적용하는 목적이면 내용은 따로 바꾸지 않아도 된다. 블로그 내용 갱신시 push하는 브랜치 이름만 자신에 맞게 바꾸어 주면 된다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
name: Build and Deploy to Github Pages
on:
push:
branches:
- master # Here source code branch is `master`, it could be other branch
jobs:
build_and_deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
# Use GitHub Actions' cache to cache dependencies on servers
- uses: actions/cache@v3
with:
path: vendor/bundle
key: $-gems-$
restore-keys: |
$-gems-
# Use GitHub Deploy Action to build and deploy to Github
- uses: jeffreytse/jekyll-deploy-action@v0.4.0
with:
provider: 'github'
token: $ # It's your Personal Access Token(PAT)
repository: '' # Default is current repository
branch: 'gh-pages' # Default is gh-pages for github provider
jekyll_src: './' # Default is root directory
jekyll_cfg: '_config.yml' # Default is _config.yml
jekyll_baseurl: '' # Default is according to _config.yml
bundler_ver: '>=0' # Default is latest bundler version
cname: '' # Default is to not use a cname
actor: '' # Default is the GITHUB_ACTOR
pre_build_commands: '' # Installing additional dependencies (Arch Linux)
workflow를 추가했다면 이제 해야할 일은 gh-pages라는 이름의 브랜치를 만들어주면 된다. 꼭 gh-pages가 아니더라도, workflow에서 - uses: jeffreytse/jekyll-deploy-action@v0.4.0의 branch값과 일치만 시켜주면 된다. gh-pages는 blog의 내용에 해당하는 렌더링된 _site의 내용만을 가지고 있다. master브랜치 혹은 원래 사용하던 브랜치는 마찬가지로 소스코드가 저장이 되는 형태로 레퍼지토리를 관리하면 되는데 해당workflow가 마스터 브랜치에 push가 일어날 경우에 자동적으로 렌더링을 하고 나서 gh-pages브랜치에 해당 내용을 푸시하는 구조로 이해하면 된다.
$ git checkout --orphan gh-pages
$ git rm -rf .
$ git commit --allow-empty -m "initial commit"
$ git push origin gh-pages
깃헙 블로그 레퍼지토리에서 [Settings]→[Pages]→[Build and deployment]에서 블로그에 사용할 브랜치를 gh-pages로 변경한 후에 마스터 브랜치에 push를 하면 로컬과 같은 결과물을 Github Pages에서도 확인할 수 있을 것이다.
추가적으로 gh-pages가 변경되지 않을 경우에는 [Settings]→[Actions]→[Generals]→[Workflow permissions]를 확인해보자.
Github Workflow & Action
GitHub Workflow와 GitHub Actions은 GitHub에서 제공하는 기능으로, 소프트웨어 개발 및 배포 작업의 자동화를 위한 도구이다. 사실 Github에 이러한 기능이 있다는 것을 이번에 공부하면서 처음 알게 되었다.
Github Actions
GitHub Actions는 작업을 실행하는 가상 환경을 제공하며, 작업이 실행되는 환경에 대한 컨테이너 이미지를 정의하고 사용자가 지정한 작업 단계를 실행한다. 작업은 트리거 이벤트에 응답하여 실행되며, 테스트, 빌드, 배포 등의 작업을 수행할 수 있다. GitHub Actions은 작업을 구성하고 실행하는 데 사용되는 YAML 기반의 파일인 .github/workflows 디렉토리에 저장된다.
깃헙 블로그를 사용해본 유저라면 많이 받아보았을 이 메일이 GitHub Actions의 결과이다. Github pages에 해당하는 레퍼지토리는 푸쉬시에 자동으로 pages-build-deployment를 실행시켜주는 것이다.
Github Workflow
GitHub Workflow는 코드 저장소에서 이벤트(push, pull request 등)가 발생할 때 실행되는 자동화된 작업 흐름을 정의하는 YAML 파일이다. 이번 포스팅에서 다룬 내용이 이것이다. 이 작업 흐름은 CI/CD(Continuous Integration/Continuous Deployment)를 구현하거나 코드의 빌드, 테스트, 배포 등 다양한 작업을 자동으로 수행하는 데 사용된다. GitHub Workflow는 프로젝트의 .github/workflows 디렉토리에 YAML 파일로 정의되며, 저장소에 푸시되는 등의 이벤트에 응답하여 작업을 실행한다.