しばたテックブログ

気分で書いている技術ブログです。

Redmine 3.4.2でrake redmine:migrate_from_tracをエラー無く動作させるためのパッチを書きました

タイトル通りです。

Trac LightningからRedmineへ移行するにあたり、公式?に用意されていた移行ツールがRedmine 3.4.2ではエラーが出て動かなかったので、とりあえずエラー無く動作させるパッチを書いてみました。

Redmine 3.4.2でrake redmine:migrate_from_tracをエラー無く動作させるためのパッチ

パッチはGistに上げています。

Redmine 3.4.2でrake redmine:migrate_from_tracをエラー無く動作させるためのパッチ

gist.github.com

パッチの詳細や使い方についてはコメントに書いてあります。

Tracからのデータ移行に関して

RedmineでTracからデータ移行をするにはrake redmine:migrate_from_tracコマンドを使います。
だだ、このコマンドはTrac 0.11あたりを対象としており、作られた時期もかなり昔の様です。
残念ながら現在はコードのメンテナンスが行われておらず、何も考えず実行すると以下の様にエラーになってしまいます。

f:id:stknohg:20170930120311p:plain

出ているエラーはRedmine内部で使用しているRailsのバージョンが上がったことが原因であるため、本エントリのパッチは単純にエラーとなっている個所を新しいRailsに合わせた形に直しているだけとなります。

パッチを当てた後で再度rake redmine:migrate_from_tracを実行すると下図の様にウィザードを進めることができ、エラー無くデータを移行することができます。

f:id:stknohg:20170930120350p:plain

f:id:stknohg:20170930120411p:plain

注意事項

Ver.1.0以降の新しいTracだとデータの内部形式が異なる様で、本パッチを適用しても「データベースが見つからない」旨のエラーが出てしまいます。
新しいバージョンのTracからデータを移行したい場合は気合いでなんとかするしかない様です。

私の場合、Trac Lightningは新しいバージョンでもTrac 0.12だったので運よくパッチだけで済みました...

このツールに関して、エラーに関するIssueも幾つか出ているのですが、中の人たちの優先度も低い様で改善される見込みは無いと思われます。
(仮に私が中の人だとしても間違いなく優先度は低くするでしょうし、むしろこのツールをサクッと捨てると思います...)

また、Gistにも記載していますが、Trac 0.12のデータを移行する際は、

migrate_from_trac does not support trac 0.12

のパッチも適用しておく必要があります。
これはTrac 0.12から時刻データの内部保持形式が変わった(UnixTimeからマイクロ秒単位のUnixTimeに変更されている)のに対応するパッチとなっています。

PowerShellでmkdirしたディレクトリにcdする方法

クラスメソッドさんの

dev.classmethod.jp

が人気なので便乗してPowerShellだとどうすれば良いか軽く書いておきます。

本エントリの内容はWindows 10、PowerShell 5.1、PSReadline 1.2な環境で動作確認しています。

1. $$自動変数を使う

Bashでは$_が「ひとつ前に実行したコマンドラインの最後の引数」となっていますが、PowerShellで$_は「パイプラインで現在処理されているオブジェクト」を表す自動変数なので使えません。

PowerShellでは代わりに$$を使います。
$$は正確には「セッションが受け取った最後の行にある最後のトークン」なのですが、コマンド実行直後であれば「ひとつ前に実行したコマンドラインの最後の引数」と同じに使えます。

実行例はこんな感じです。

mkdir .\very\very\long-directory
cd $$

2. パイプラインでつなぐ

PowerShellではmkdir関数に成功すると作成されたディレクトリオブジェクト(System.IO.DirectoryInfo)を返します。
このため、この値をパイプラインでつなぎcd(Set-Location)に引き渡すことが可能です。

mkdir .\very\very\long-directory | cd

ただ、この方法でロケーションを移動した場合、プロンプトに表示されるロケーションが、

PS Microsoft.PowerShell.Core\FileSystem::C:\very\very\long-directory > 

の様に先頭にPSProvider(Microsoft.PowerShell.Core\FileSystem::の部分)が修飾されてしまう場合があり、見た目としては非常によろしくありません...

一応、

mkdir .\very\very\long-directory | % { $_.FullName } | cd

# or

mkdir .\very\very\long-directory | cvpa | cd

のように一旦%(ForEach-Object)や、cvpa(Convert-Path)をはさむことで回避はできるのですが、冗長で本末転倒です...

3. cd → Alt + . (PSReadline Windowsキーバインド)

PSReadlineを個別にインストールするか、標準でPSReadlineがインストール済みのWindows 10/Windows Server 2016環境でこの方法を使うことができます。

PSReadlineのデフォルトのキーバインドではAlt + .YankLastArgという機能で割り当てられており、「ひとつ前に実行したコマンドラインの最後の引数」を取得することができます。
このため、cdAlt + .の順に入力することで直近に入力したパスを補完することが可能です。

なお、キーバインドの割り当ては以下のコマンドで確認することができます。

Get-PSReadlineKeyHandler | ? { $_.Function -eq "YankLastArg" }

結果

Key   Function    Description
---   --------    -----------
Alt+. YankLastArg Copy the text of the last argument to the input

4. cd → ESC → . (PSReadline Emacsキーバインド)

PSReadlineではSet-PSReadlineOptionによりキーバインドを変更することができます。

Set-PSReadlineOption -EditMode Emacs

とすることでキーバインドをEmacs風にすることができ、この場合、cdESC.の順に入力すれば「ひとつ前に実行したコマンドラインの最後の引数」を取得することができます。

ちなみに、

Get-PSReadlineKeyHandler | ? { $_.Function -eq "YankLastArg" }

の結果は以下の様に変更されています。

Key      Function    Description
---      --------    -----------
Alt+.    YankLastArg Copy the text of the last argument to the input
Alt+=    YankLastArg Copy the text of the last argument to the input
Escape,. YankLastArg Copy the text of the last argument to the input
Escape,= YankLastArg Copy the text of the last argument to the input

5. ESC → k 0 cw cd (PSReadline viキーバインド)

PSReadlineはVer.1.2からvi風のキーバインドをサポートしています。

Set-PSReadlineOption -EditMode Vi

とするこでキーバインドをvi風にすることができます。
あとは元記事同様に、ESCk 0 cw cdで前回のコマンド呼び出し文字列置換を行う事ができます。

6. mkdir と cd を同時に実行する関数をあらかじめ定義しておく

独自の関数を作るのであれば好きなように作ってしまうのが良いと思います。

mkdir自体がNew-Itemコマンドレットをラップした関数なので、本格的な関数を作りたい人はmkdirの定義を確認してみると良いでしょう。
役に立つ情報を得ることができるはずです。

本エントリでは元記事に近い形の簡易な関数を紹介するにとどめておきます。

function mkdir-cd {
    mkdir $args[0] | cvpa | cd
}

※なお、PowerShellでは&&は予約語となっていますが、サポートされておらず使えません。

最後に

とりあえずこんな感じです。

BashやZshほどではないですがPowerShellでもいろいろな方法を選べますので是非試してみてください。

Desired State Configuration Core (DSC Core)が発表されました

発表されてからちょっと時間が経ってしまいましたがざっくりまとめておきます。

公式情報はコチラ

blogs.msdn.microsoft.com

以前PowerShell 6.0、PowerShell Coreのロードマップが発表された時はWindows PowerShell Desired State Configuration(以後PowerShell DSC)について言及されませんでしたが、今回はじめてPowerShell DSCの今後について言及されました。

本エントリではこの内容について説明していきます。

これまでのPowerShell DSC

PowerShell DSCとは何ぞや?といった話についてはぎたぱそ先生の記事が全てですのでそちらでご確認ください。

www.atmarkit.co.jp

adventar.org

これまでのPowerShell DSCについては、Windowsで動作するもの、Linuxで動作するものの2種類があり、それぞれ、

1. Windows PowerShell Desired State Configuration

  • WMIを基盤としている
  • Windows Management Framework (WMF)の一部として提供されており、管理にはPowerShell 4.0~5.1を必要とする
  • DSC ResourceはCまたはPowerShellで記述する

2. Desired State Configuration for Linux(DSC for Linux)

  • OMIを基盤としている
  • PowerShellがクロスプラットフォーム化する前に生まれているため、管理にPowerShellは使わずPython 2.4~3.4を必要とする
  • DSC ResourceはCまたはPythonで記述する

といった特徴があります。  

ちなみにDSC for Linuxについてはこのブログでも試していますので以下の記事を参考にしてください。

blog.shibata.tech

Desired State Configuration Core (DSC Core)

PowerShellがPowerShell Coreとなり.NET Coreを基盤としたクロスプラットフォームなツールになることにあわせて、PowerShell DSCも.NET Core/PowerShell Coreを基盤としたDesired State Configuration Core (以後DSC Core)として発展させていくとの事です。

DSC Coreについて以下の方向性が挙げられています。

  • WMIへの依存をなくす
  • WMFへの依存をなくす
  • xcopyで配布可能なパッケージとする
  • WMIを使わないC/C++、Python、PowerShellで書かれたDSC Resourceをサポートする
  • PowerShell Core/.NET Coreを必要とする

ざっくり言ってしまえばクロスプラットフォーム化のためにPowerShell Core/.NET Coreを基盤とし、WMIやWMFへの依存(要はWindows依存)を取り除く方向になります。

DSC Coreの目指すことろ

こちらについてはPowerShell Blogの内容をそのまま引用します。

Our goals with DSC Core are to minimize dependencies on other technologies, provided a single DSC for all platforms, and position it better for cloud scale configuration while maintaining compatibility with Windows PowerShell Desired State Configuration.

DSC Coreの下位互換性

目指すところは分かりますが、これまでのPowerShell DSCとの互換性をどう取るのかは非常に重要であり、もっとも難しい問題だと思います。

この点についてPowerShell Blogでは以下の様に述べられています。

  1. DSC Resourceに関しては.NET Standard 2.0の互換性で既存のリソースはそのまま動く様にする

  2. コマンドレットに関しては従来のPowerShell DSCとの互換を取らず、新しいコマンドセットを提供する

  3. Azure DSC ExtensionはDSC Core用に新規のものを提供する

  4. Pullサーバーとの通信に関して、DSC Coreでもこれまで通りのプロトコルを使い既存のPullサーバーと通信できる様にする

  5. Configurationに関しては、これまで通り変更が無い様にし、PowerShell 6.0でコンパイルしなおすだけで使える様にする

PowerShell Blogでも注記されていますが、これらの点についてはあくまでも現時点での計画です。

私見ですが、正直これらをすべて完璧に満たすのは難しいと思っていますので、今後の状況によっていろいろ変化があると思われます。

DSC Coreのリリース時期

DSC Coreのリリース時期に関して、先ずはAzure向けに年末までに最初のリリースを出すそうです。
(流石に早すぎるのでここでの"リリース"はアルファ版とかだと思います...)

PowerShell DSCがクロスプラットフォーム化するメリットを一番享受できるのがAzureでしょうし、環境自体が日々更新され新しくなっていくAzureにフォーカスするのは妥当な判断だと思います。
(逆にWindowsを中心としたオンプレ環境だと今のPowerShell DSCを新しくするメリットがほとんどないように思われます...)

まとめ

ざっくりとですがDSC Coreについてまとめてみました。

正直なところ、DSC Coreの仕組みやPowerShell Blogで述べられている事がどこまで実現可能かについて結構疑問点があります。

ですが、今それについてあれこれ言っても仕方ないとも思っているので今後の情報で疑問を解決していきたいと思います。