トップ > Mercurial

Chef SoloでTracLightningぽい環境を構築してみた

trac Chef TracLighting Mercurial Jenkins

Chefが面白そうなのでいろいろやってみた結果、TracLightning＋hglightぽい環境を構築できるようになったのでまとめを書いてみることにした。TracLightningと違うのはSubversion/MavenがないとかTracプラグインが最小限しかないくらいかな。

f:id:re_guzy:20130525220055p:plain

動作確認は次の環境で行った。

  • Chef 11.4.0
  • Windows 7 SP1 Professional(x86)
  • Windows Server 2008 R2 Standard
  • Windwos Server 2012 Standard

Chefリポジトリはここで、cookbook名はtracwithhgとした。

tracwithhgがやっていること

  1. Visual C++ 2008 ランタイムのダウンロードとインストール
    • Python の動作に必要なため
  2. Python 2.7.4のダウンロードと"C:/Trac/python"への展開
    • easy_install のインストールも
  3. Mercurial 2.5.4のダウンロードとインストール
    • attribute(node['hg']['need_build'])にtrueを指定すると、MinGWをインストールして、ソースからビルド後インストールする。
  4. Trac 1.0.1のダウンロードとインストール
    • Wikiに関しては TracJa 1.0を使っている。
    • プロジェクト作成時に wiki load してるだけ。
  5. TracAccountManagerPlugin 0.4.3のダウンロードとインストール
    • 認証方式にDigestを指定した場合のみ
    • 認証方式にSSPIを指定した場合はインストールされない
  6. TracMercurialPlugin 1.0.0.3のダウンロードとインストール
  7. Apache 2.2.24のダウンロードと"C:/Trac/apache"への展開
  8. ファイアーウォールの例外にapache追加
  9. JRE 7u21のダウンロードと"C:/Trac/jre"への展開
  10. .NET Framework 3.5 SP1 の有効化
    • JenkinsのWindowsサービス化に必要
    • Windows 8/Windows Server 2012 ではデフォルトで無効化されているため必要
  11. Jenkins 1.514のダウンロードと"C:/Trac/jenkins"への展開＆Trac(Jenkins)のWindowsサービス化
  12. Trac(Apache)のWindowsサービス化
    • Twitter Bootstrapで作成したHTMLをApacheで公開
    • mod_wsgi 3.3のダウンロードと有効化
    • SSPI認証なら mod_auth_sspi 1.0.4のダウンロードと有効化
    • Tracをmod_Wsgiで公開できるようにhttpd.conf書き換え

準備

  1. Installing Chef Client on Windows - Chef - Opscode Open Source WikiからChefのインストーラをダウンロードしてインストール
  2. toruuetani / Chef-repository-TracWithHg ― Bitbucket を任意の場所（「C:/Chef」とか）にclone
  3. Chefに同梱されている「win32/registry.rb」を修正（参照：Chef Solo で invalid byte sequence in Windows-31J / invalid byte sequence in UTF8 に遭遇したときの対処をいくつか - 記憶は削除の方向で）

実行方法

cloneしてきたChefリポジトリに同梱されている「install.bat」を管理者権限で実行するだけ。
※Windows Server 2012 の場合、インストールメディアがDドライブにセットされている必要あり。Dドライブ以外にインストールメディアをセットする場合、attribute（node['netfx3']['source']）を環境に合わせて修正すること。

プロジェクト作成方法

create-hg-project.batを実行するだけ。
最低限Tracプロジェクト名を指定する必要あり。Mercurialリポジトリをcloneする場合はcloneするURLを指定すること。

既存プロジェクトに管理するMercurialリポジトリを追加する場合、create-hg-append.batを実行してTracプロジェクト名とMercurialリポジトリ名を指定する。Mercurialリポジトリをcloneする場合はcloneするURLを指定すること。

Digest認証の場合、初期ユーザーとして次の２アカウントを用意する。

  • アカウント: admin, パスワード: admin
  • アカウント: guest, パスワード: guest

TODO

  • Jenkinsでプロジェクト作成
  • Jenkinsでバックアップ
  • Jenkins関連ができたらhglightにも反映すること

■

Mercurial TortoiseHg

これの続き。
参考URL : http://mercurial.selenic.com/wiki/Subrepository

Mercurial 2.0 ( TortoiseHg 2.2 ) で仕様が変わったらしく、以前の方法だとうまくいかない。

[subpaths]
subrepo_name = https://bitbucket.org/toruuetani/virtualenv-scaffold

たとえばメインリポジトリのクローン元が https://bitbucket.org/toruuetani/hoge の場合、以下のようにする。

[subpaths]
https://bitbucket.org/toruuetani/hoge/subrepo_name = https://bitbucket.org/toruuetani/virtualenv-scaffold


ちなみに これで作ったバッチは以下のようになる。

@ECHO OFF
SET ROOT_DIR=%~DP0
SET TOP_REPO=PATH_TO_TOP
SET SECOND_REPO=PATH_TO_SECOND
SET THIRD_REPO=PATH_TO_THIRD


SET TOP_HGRC=%ROOT_DIR%\.hg\hgrc
SET SECOND_HGRC=%ROOT_DIR%\SECOND_DIR\.hg\hgrc


:CREATE_TOP
hg init
ECHO [paths]>%TOP_HGRC%
ECHO default = %TOP_REPO%>>%TOP_HGRC%
ECHO;>>%TOP_HGRC%
ECHO [subpaths]>>%TOP_HGRC%
ECHO %TOP_REPO%/subrepo_second = %SECOND_REPO%>>%TOP_HGRC%


:CREATE_SECOND
IF NOT EXIST %ROOT_DIR%SECOND_DIR MKDIR %ROOT_DIR%SECOND_DIR
CD /D %ROOT_DIR%SECOND_DIR
hg init
ECHO [paths]>%SECOND_HGRC%
ECHO default = %SECOND_REPO%>>%SECOND_HGRC%
ECHO;>>%SECOND_HGRC%
ECHO [subpaths]>>%SECOND_HGRC%
ECHO %SECOND_REPO%/subrepo_third = %THIRD_REPO%>>%SECOND_HGRC%


:UPDATE
CD /D %ROOT_DIR%
hg pull
hg update -C


:END
PAUSE

TortoiseHg 2.x 入門記事にMercurialコマンドリファレンス追記

Mercurial TortoiseHg

最近書いてる TortoiseHg 入門記事に、Mercurialのコマンドリファレンスを追記した。
Windows＋TortoiseHg 2.x で始めるMercurial

今回改めて Mercurial コマンドのヘルプを調べてみたけど、ほとんどオプションは使ってない。このあたりが Git との違いなんだろうな。

TortoiseHg 2.x 入門記事にMercurial採用理由追記

Mercurial TortoiseHg

以前書いてた TortoiseHg 入門記事を Ver.2.2 ベースで書きなおした記事に、なぜMercurialを採用するのか追記した。
Windows＋TortoiseHg 2.x で始めるMercurial

ある程度分量があってはてなでは書きにくいことと、最近ドキュメントはSphinxで書いたほうが書きやすいので、すべてSphinxで書きなおした。
このあとはブランチの使い方に言及していく予定。果たしていつになるのか・・・

subpathsを使ったリポジトリをcloneする方法

Mercurial
2012/01/25 追記
Mercurial 2.0 以降は これ を参照

subrepoを使わない場合とか、subrepoを使ってもsubpathsを使ってない場合なら、リポジトリは普通にcloneできる。ただしsubrepoかつsubpathsを使っていると、普通にcloneすると失敗する。

何故かというと、subpathsはhgrcにsubrepoが参照するリポジトリのパスを格納しているから。
cloneしてもhgrcは作成されず、hgrcは自分で作成しないといけない。

なのでhgrcにsubpathsを格納しつつpullすれば、cloneと同じような効果が得られる。
ただし毎回手打ちでやるのも面倒なので、バッチファイルを用意してみた。２段階までネストに対応。

各リポジトリ（トップ、ネスト１段階目、ネスト２段階目）のパスと、ネストしたリポジトリを格納するディレクトリを変更すれば使えるはず。ディレクトリ構成はこんな感じ.

PATH_TO_TOP
├─.hg
├─SECOND_DIR
    ├─.hg
    ├─THIRD_DIR
        ├─.hg
@ECHO OFF
SET ROOT_DIR=%~DP0
SET TOP_REPO=PATH_TO_TOP
SET SECOND_REPO=PATH_TO_SECOND
SET THIRD_REPO=PATH_TO_THIRD


SET TOP_HGRC=%ROOT_DIR%\.hg\hgrc
SET SECOND_HGRC=%ROOT_DIR%\SECOND_DIR\.hg\hgrc


:CREATE_TOP
hg init
ECHO [paths]>%TOP_HGRC%
ECHO default = %TOP_REPO%>>%TOP_HGRC%
ECHO;>>%TOP_HGRC%
ECHO [subpaths]>>%TOP_HGRC%
ECHO subrepo_second = %SECOND_REPO%>>%TOP_HGRC%


:CREATE_SECOND
IF NOT EXIST %ROOT_DIR%SECOND_DIR MKDIR %ROOT_DIR%SECOND_DIR
CD /D %ROOT_DIR%SECOND_DIR
hg init
ECHO [paths]>%SECOND_HGRC%
ECHO default = %SECOND_REPO%>>%SECOND_HGRC%
ECHO;>>%SECOND_HGRC%
ECHO [subpaths]>>%SECOND_HGRC%
ECHO subrepo_third = %THIRD_REPO%>>%SECOND_HGRC%


:UPDATE
CD /D %ROOT_DIR%
hg pull
hg update -C


:END
PAUSE

subrepoをさらに便利に使うためにはsubpathsを使おう

Mercurial
2012/01/25 追記
Mercurial 2.0 以降は これ を参照

これの続き。

subrepoは確かに便利なんだけども、あるシチュエーションでは使いにくいことになる。

  • サーバの名前が変更されたとき
  • 場所によってpushする先が違うとき（滅多にないだろうけど）

例えば、あるマシンAではsubrepo Aにpushしたりpullしたいが、あるマシンBではsubrepo Bにpushしたりpullしたい、だけど履歴は共有したい、なおかつマシンBからsubrepo Aはアクセス出来ない場合（マシンAを中心に履歴は共有する）。あるのか？というぐらい限定的だけども、現在自分が困っていて、その解決策っぽいのが見つかったのでメモ。

解決先はこれ -> http://mercurial.selenic.com/wiki/SubrepoRemappingPlan

前回 .hgsub にリポジトリのURLを記述していたが、今回はリポジトリのエイリアスを記述する。

echo subdir = subrepo_name > .hgsub

.hgsubはこうなる。

subdir = subrepo_name

次にメインリポジトリの.hg/hgrcに[subpaths]を記述する。

[subpaths]
subrepo_name = https://bitbucket.org/toruuetani/virtualenv-scaffold

subdirとsubrepo_nameはかぶらないようにすること。同名だとsubrepoがネストしてたりすると余計な置換が働いて、正しいURLにならないことがある？


.hg/hgrcは他のリポジトリに伝搬しないので、実際にやりとりしたいリポジトリを記述すればOK。

subrepoを試してみた

Mercurial

前から気になってた、Mercurialのsubrepoの使い方がなんとなくわかったのでメモ。

何がうれしいのか

別管理のリポジトリを一緒に扱える。具体的には、共通ライブラリは別のリポジトリで管理しつつ、それを利用するアプリのリポジトリの下に共通ライブラリのリポジトリを配置できる。Subversionで言うところのベンダーブランチとかsvn:externals。

ベンダーブランチ/svn:externalsよりもうれしいのは、アプリ側のリポジトリからライブラリ側のリポジトリのリビジョンが指定できること。アプリ側のリポジトリを特定のリビジョンに更新したら、ライブラリ側のリポジトリもその時指定していたリビジョンに更新される。これはかなり便利。

作り方

まずはアプリ側のリポジトリ生成。これは普通に作る。

hg init

次にディレクトリを作って、ライブラリのリポジトリを作る。新規リポジトリをつくってもいいが、それだとあまり意味が無いので、既存のリポジトリをcloneする。

mkdir subdir
cd subdir
hg clone https://bitbucket.org/toruuetani/virtualenv-scaffold .

最後にsubrepo設定。

cd..
echo subdir = https://bitbucket.org/toruuetani/virtualenv-scaffold > .hgsub

.hgsubの中身はこんな感じで、配置先ディレクトリ = ターゲットのリポジトリパス（ディレクトリでもURLでも可）とする。

subdir = https://bitbucket.org/toruuetani/virtualenv-scaffold

.hgsubをコミットする。

そうするとsubdirが管理下に入るのでコミットする。

コミットすると.hgsubstateがリポジトリに追加される。このファイルに、ライブラリ側のリビジョンが記録される。

この状態だとライブラリ側のリポジトリはdefaultブランチの最新なので、好きなリビジョンに更新する。

cd subdir
hg up c59d68bcc05c

そうすると.hgsubstateもそのリビジョンを指すようになるのでコミット。

こうしてできたアプリ側のリポジトリをcloneして、最新のリビジョンにupdateするとライブラリ側のリビジョンも[c59d68bcc05c]まで更新される。


もちろんライブラリ側のリポジトリは普通のリポジトリでもあるので、変更したらclone元にpushもできる。まだ使い始めたばかりだが、これはかなり便利な気がする。