devGitHubHexo

travis ci를 이용한 hexo 자동 배포 구현기

intro

hexo는 지킬(Jekyll)과 같은
SSG(Static Site Generator: 정적 사이트 생성기)로
Markdown 문서를 템플릿,css 혹은 사용자가 정의한 설정들을 합하여
html 사이트 문서로 만들어 주는 것이다.

즉 프로그램밍의 과정으로 비유하자면
내용을 채워주는 Markdown 문서가 프로그래밍 소스라면
hexo는 소스를 결과물로 컴파일 해주는 빌드툴이고
html사이트를 구성하는 html,css 등의 파일들이
빌드 결과물이라고 할 수 있다.

요는
SSG를 이용한 사이트 운영에서는 빌드 가 반드시 필요하다.
그리고 첫 포스트에서 생각했다시피 모바일 사용에서
가장 큰 걸림돌이었다.

뭐지?
이건 너무 불편한데?
다들 이런 상태로 이걸 쓰겠다고?
그러다가 이걸 해결할 정보를 발견하였다.

역시 난 머리가 굳은 것이 확실하다.
왜 빌드라는 것을 인지하면서 CI를 이용할 생각을 하지 않았을까.
나이를 먹어서 그런지.. 참 서글프다.

위의 글의 아이디어 핵심은 다음과 같다.
hexo의 sources폴더만 source브렌치로 따로 관리해서
포스트등의 추가,수정,삭제의 변화 커밋이 발견되면
travis CI를 이용하여 빌드후 public 폴더에 생성된
결과물들(html,css등)을 master 브렌치에 커밋한다.
그러면 깃허브 페이지에서는 master브렌치에 있는 html이 뜨게 되서 이용이 가능하다.

저 글에 적힌 내용대로 삽질ㄱㄱ~

result

결과부터 말하면 대성공!
이젠 깃허브 홈피가서 new파일로 post할 마크다운 문서만 만들어서
모바일로 작성해서 commit 버튼 누르면 자동으로 포스팅 된다.
node.js나 git도 아예 설치할 필요가 없이 모바일에서 아예 가능하다.ㅋㅋ
나와 같은 고민들을 가진 사람이라면 어서 저글대로 시도해보라.

log

사실 시행착오가 좀 있었다.
저 분이 좀더 자세히 포스팅 했다면 시행착오가 적었을텐데 ㅠㅠ
검색하다 하나의 자료를 더 발견: http://kflu.github.io/2017/01/03/2017-01-03-hexo-travis/
이 것까지 참고해서 해결하였다.

위 2포스트를 이용하면 해결이 가능한데 팁을 굳이 정리를 해보자면

before install 작업은 필요없다.
before install에서 “npm install -g hexo” 할 필요가 없다.
package.json에 지금까지 했던 dependency가 들어 있기 때문에
package.json을 sources 브렌치에 추가하고
install에서 npm install만 하면 사실 다 해결된다.

이메일 설정시 에러
github email 세팅에서
“Keep my email address private”,
“lock command line pushes that expose my email” 설정이 되어있는 경우
개인 이메일의 드러남을 막기 위해 noreply이메일을 얻을 수 있다.
나의 경우에는 “13996827+rkaehdaos@users.noreply.github.com“이며
git의 user.email에 이걸 설정했다.
저 설정 안쓰는 사람이면 무관한 이야기다.

빌드 시간은 매우 긴 50초
생각보다 빌드 시간이 오래 걸린다.
사실 1분도 안걸리는 시간이라 (보통 40~50초)
개인적으로 너무 예민하게 반응하는건가 라는 생각도 든다.

허나 job log 뜨는 것을 보노라면 준비에서 시간 다 먹고
실제 빌드는 5초도 안되는 것이 보이기에 더 속이 타는 수도 있다.
(실제 로컬에서 hexo g 하면 5초도 안걸린다.)
나처럼 참을성 없는 사람들은 젠킨스나 도커를 이용해서
미리 npm설치하고 ci를 구성하면 배포하는 시간까지
포함해도 아마 10초면 될듯 하다.

theme는 repo에 포함하자
사실 source 브렌치를 최대한 가볍게 하고자
처음에는 theme는 repo에서 제외하고 before script에서 다운받았다.
hexo의 테마는 git으로 다운이 가능하다.
기본테마인 landscape는 다음과 같이 내려받을 수 있다.

1
git clone https://github.com/hexojs/hexo-theme-landscape.git themes/landscape

이러면 사실 원격 CI에서 문제가 발생한다.
git안에 git이 또 들어가면 submodule로 관리하자.

이렇게 해도 사용이 가능한데 사용자가 저 테마를 수정 했을 경우가 문제다.
테마의 로고나 그림을 자기에게 맞게 수정을 했다던지..
카테고리 depth를 더 깊게 하기 위해서 수정하고 css를 조정했다던지
구글 에드 센스등의 코드를 삽입했다던지.. 등의 커스터마이징이 되었을 경우
위의 방법으론 방법이 없기 때문에 사실상 theme는 위의 방법이 아닌
그냥 repo에 add하는 것이 가장 속편하다.

.travis.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
language: node_js
## TravisCI에 pre-install된 버전을 쓰는것이 속도에 유리
node_js:
- "8.9.1"  
# Hexo source는 sources 브렌치에서 관리
branches:
  only:
  - sources
install:
- npm install
before_script:
- git config --global user.name 'GeunChang Ahn <rkaehdaos>'
- git config --global user.email '13996827+rkaehdaos@users.noreply.github.com'
- sed -i "s/__GITHUB_TOKEN__/${__GITHUB_TOKEN__}/" _config.yml
script:
# 2번째 포스트 레퍼런스처럼 package.json에 script로 build로 hexo 작업 정의
 - npm run build

conclusion

이로 인해서 얻는 장점은 뭐가 있을까.

1.빌드 신경쓸 필요가 없어짐
가장 큰 장점이다. CI에서 얻는 장점 모두 다 적용.
빌드시간이 짧아서 부담은 없는데 귀찮았던 것은 사실이다.

2.Hexo 없어도 post가 가능하다.
server 등 명령어 사용을 위해 hexo 있는게 편하지만
말그대로 마크다운만 github에 올려도 post가 올라간다.
말 그대로 올리기 위해서 필수적이진 않다.

3. 백업이 필요없다.
빌드되어 깃허브에 올라가는 것은 결과물이므로
나중에 마이그레이션이나 다른 형태의 결과물을 내기 위해 마크다운 백업이 필요하다. 여기서는 sources브렌치로 소스를 어차피 관리하기 때문에 따로 백업을 할 필요가 없다.

처음 SSG 시작하는 분들에게 도움이 되시길

공유하기