Archives

GitLab+JenkinsでTeXを自動ビルドして論文作成と精神を加速させる

Wordを使いながら、こう考えた。

量が増えれば処理が鈍る。画像を移せば落とされる。意地を通すはWordの方だ。とかくにMS帝国は住みにくい。住みにくさが高じると、安い所へ引き越したくなる。どこへ越しても住みにくいと悟った時、TeXが生まれて、GitLab+Jenkinsが出来る。

かの夏目青年は30にしてこのように悟ったわけであるが、今どきの大学院生である私もそのとおりであると思う。Wordを使わない理由は、

  • ページ数が増えると重い
  • 画像のレイアウトが思ったようにならない
  • 勝手にレイアウトを変える (OFFに出来ることは出来る)

など。論文の終盤でこのような理不尽の嵐にさらされて精神を病むものは後を絶たないと聞く。責任者に問いただす必要があるかどうかは別にして、現実を変えたいと願うならばTeXを使うと良い。TeXとは一言で言ってしまえば図とか文とか表を配置するための言語で、Knuth御大がムシャクシャして作ったものだ。

よしではTeXを使おうと思っても準備が必要で、ちょっとググるとLaTexだのpTeXだのXeLaTeXだの出て来て頭がフットーしそうになる。なのでここではそれを簡単に整理してみたい。まずTeXもLaTeXもpTeXもXeLaTeXも*.texファイルを扱うコンパイラで、その目指すところもすべて同じで、

  • 目標: *.texファイルから文書を作る

ことである。この「文書」というのが歴史的にDVIからPostScript、PDFへと変遷してきて、それぞれにコンパイラや変換ソフトが登場してきた。XeLaTeXなんかは*.texからPDFを直接作成できる。

もう一つの軸は多言語対応である。TeXは英語の文書をコンパイルするために作られたので、日本語の文書に対応するにはそれなりの拡張が必要になる。TeXの日本語拡張版がpTeXである。TeXの高機能版であるLaTeXの日本語拡張版はpLaTeXだ。さらにLaTeXの進化版のLaTeX2eの日本語拡張版のpLaTeX2eというものもある。だいたい重要な所をまとめると次の表みたいな感じになる。

tex-900x808

「XeTexとかLuaTeX使えば最強じゃね?」と思われるかもしれないが、そのとおりである。しかもこれらはフォントの指定も出来る。

しかしそれを阻むものがある。学会指定のスタイルファイルである。LaTeX2eもしくはpLaTeX2eに対応したテンプレートが配布されることが多いような気がする。本文のtex記法自体はだいたい使いまわせるので、

  • スタイルが指定されてない: XeLaTeX (LaTeXをサポートしたXeTeX)
  • スタイルが指定されている: みんなそれを使うしかないじゃない(pLaTeX2eが多い)

という具合である。なぜLuaTeXじゃなくてXeLaTeXなのかというと、LuaTeXがまだ評価版であるということ、そのために情報が少ないことが原因である (LuaTeXのバージョン1.0は2012年リリースが予定されていたがまだらしい)。

思わず Lua で LaTeX してみた ~LuaTeX で日本語しない件について~  [電脳世界の奥底にて] 

Differences between LuaTeX, ConTeXt and XeTeX – Stack Exchange

ではインストールから出力するまでにやることを書く。

1. インストール

texliveをインストールする。上述のコンパイラが全部インストールされるので便利。windows/mac/linuxそれぞれ利用可能。しかも編集&閲覧ソフトのTeXWorksも同梱される。macではTeXnicleの方がおすすめだけど。

Installing TeX Live over the Internet

2. スタイルを整える

いろいろググったりした結果できたXeLaTeXのファイル群をGitHubに置いておく。thesisとarticle-single、article-multiの2種類。thesisはchapter>section>subsection構成で、articleはsectionから始まる構成。article-multiはファイルを分散させてる。

Drunkar / tex-template

参考にしたのは以下のサイト

参考文献の管理にはBibTeXを、ソースコードのシンタックスハイライトにはmintedを使っている。

3. コンパイル

BibTeXを使っているので3回コンパイルしなければならない。

#!/bin/sh
mainfile=index
# for mac (add texlive path otherwise.)
PATH=/usr/texbin:/usr/local/bin:$PATH
ENGINE=xelatex
BIBTEX=bibtex

$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile
$BIBTEX $mainfile
$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile
$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile

後TeXnicle用のエンジンはgistに置いた。

 Drunkar / xelatex_bibtex_minted.engine

試しにgithubから取ってきてコンパイルできたらOK.

$ git clone git@github.com:Drunkar/tex-template.git
$ cd tex-template/thesis
$ sudo chmod 755 build_xelatex.sh
$./build_xelatex.sh

とすればindex.texがこんな感じでできる。

article-single, artice-multiも同様。

 4. Jenkinsでやる

まずGitLabにリポジトリを作る。

Jenkinsにも同様のプロジェクトを作ってビルドスクリプトに上記のbuild_xelatex.shを貼り付ける。必要ならパスを追加する。

スクリーンショット_022814_120729_AM

pushでビルド開始するようにgitlab pluginとかを入れる。GitLabとJenkinsが同一サーバの場合は前回の記事を参照。

GitLabとGitLab_CIとかJenkinsを同一サーバで使う場合に必要な設定

GitLabとGitLab_CIとJenkinsはそれぞれ別のユーザーで実行することが想定されています。GitLab_CIに至ってはgitlab_ciユーザーに加えてビルドを実行するgitlab_ci_runnerユーザーも必要です。

[table id=1 /]

この状態でこれらを同一サーバーにインストールすると、GitLabからプロジェクトのコードをcloneするときにAccess denied になります。パーミッションエラーです。それぞれのアプリケーションはそれぞれのホームディレクトリ以下で動いているので, 同一サーバ内だとパーミッションエラーになるわけです。

別のサーバにインストールできればいいのですが、唯一虎の子のサーバしかないということも多々あると思います。そういうときには全部ユーザーgitで動かしちゃえばオールオッケーです。

GitLab_CI , GitLab_CI runner

  • config/database.ymlのユーザーをgitに (GitLab_CI runnerは無い)
  • /etc/init.d/gitlab_ciの
    • APP_USERをgitに
    • GitLab_CI runnerはさらにAPP_ROOTを/home/git/gitlab-ci-runnerに

変更すればオッケーです。

Jenkins

Jenkinsを別ユーザで動かす – kotaroito’s notes 

を参考にして、/etc/sysconfig/jenkinsでユーザーとホームディレクトリを変更し、/var/log/jenkins/, /var/cache/jenkins/の権限を変更します。

JenkinsでGitLabのプロジェクトをビルドするには、Jenkinsプロジェクトの設定を

スクリーンショット_022414_021836_AM-5

こんな感じにすることでcloneできるようになります。8079はGitLabを動かしているポート番号です。

ひとまず動くようになるまではこれでオッケーですが、JenkinsでGitLabへのpushを景気としてビルドするにはもうちょっと手間が必要です。JenkinsにはGitLabプラグインというのがあるのですが、Repository URLに書いたパスにhttpでアクセスすることでpushイベントを登録するみたいで、今回のように絶対パスでGitLabリポジトリを登録した場合はpushに反応してくれませんでした。ですのでJenkinsに直接curlすることでhookすることにします。

curl http://localhost:8088/job/hogehoge/build することでJenkinsのhogehogeプロジェクトがビルドできることをまず確認しましょう。8088はJenkinsの動いているポートです。

そのためにgitのhooks/post-update機能を使います。

cd /home/git/repositories/oreore/hogehoge.git/ でoreoreさんのhogehoge.gitリポジトリに移動し、hooks/post-updateを有効にします。

? mv hooks/post-update.sample hooks/post-update
? chmod a+x hooks/post-update
? vi hooks/post-update

hooks/post-updateは次のように変更します。ハイライトは追加した行

#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

curl -s http://localhost:8088/job/hogehoge/build
exec git update-server-info

これでGitLabのhogehogeプロジェクトにpushするとcurl -s http://localhost:8088/job/hogehoge/build が実行されるようになります。

それでは素敵なおじさんライフを!

 

GitLab_CI「Jenkinsおじさんには勝てなかったよ…」

こんな即堕ち展開になるはずじゃなかったんだけど・・・

老獪J爺ことJenkinsの方が優れている点

  • パスを指定可能
  • 成果物を閲覧・ダウンロード可能: texコンパイルでpdfを見れる
  • プラグインが豊富
  • インストールも簡単: yumでできる

GitLabからのリポジトリ登録の手間はどっちもほとんど変わらない。同一サーバでの運用の苦労も変わらない(どちらも実行ユーザを作成することを想定しているため)。今回はtexをコンパイルしてpdfを見れるようにしたかったので、Jenkins翁の完全勝利だった。というか、現段階ではGitLab_CIの優れている点は無いと言っていいと思う。