何があった
Dockerコンテナで運用中の、Laravelで動いているとあるプロジェクトにて、gitlab-ciのコンテナビルドjobが失敗した。
原因を確認すると、ビルド中のcomposerでエラーになっていた模様。
エラーを見ると、
Installing propaganistas/laravel-intl (1.2.5): Downloading (connecting...)Downloading (failed) Failed to download propaganistas/laravel-intl from dist: The "https://api.github.com/repos/Propaganistas/Laravel-Intl/zipball/f85d7bda85ddb78a956cf7d10b68b16d0b0664fa" file could not be downloaded (HTTP/1.1 404 Not Found)
....?
404 Not Found ??
パッケージのダウンロード元が見つかりません？
つい先日までビルドできてたのに・・・。
とりあえず、何か代替えを検討しないと、
せっかく修正したコードが反映できない。
という事で、対応を検討していく。
まずやったこと
まずは見つからないパッケージが何ものかを調べ、パッケージ名が変わっていないか、導入方法が変わっていないかを調査。
するとどうやら、バージョンが上がってパッケージ名も少し変わっていたようだ。
という事で、composerの設定を変更してみる。
改めてビルドしてみると・・・・
あえなく失敗。
どうやら、パッケージのバージョンが上がって、使用しているLaravelのバージョンと合わなくなったようだ。
Laravelのバージョンは、5系と古い。
これ自体もアップグレードしたいが、それをするとコード全ての調整という一大事業になる。
今はそれを行なっている時間がなく、別の方法を検討する。
ローカル手元には、パッケージ本体がある
そう、手元には、以前composerでインストールした古いバージョンのパッケージが存在する。
これを使うことはできないだろうか？
という事で調べてみると、composerには、インストール元のリポジトリを指定する事ができる。
元々は自作パッケージなどを使用する際に指定するための設定欄のようだ。
"repositories": [
{
"type": "path",
"url": "[パッケージのディレクトリ]",
}
],
これで、composerはインストール際にまず指定したリポジトリから探してくれる。
見つからなければ、デフォルトのリポジトリから探し、従来通りに挙動してくれる。
これだ！これでなんとかなりそうだ。
うまくいきそうで行かない落とし穴
意気揚々とビルドする。
しかし、エラーに。
最初のエラーと同じく、404 not fouondに。
え、なんで？ローカルパスを指定してるんですけど。
なぜかcomposerは、まだデフォルトのリポジトリからあるはずのないパッケージを探している。
なぁぜなぁぜ？
と、大事な事を忘れていました。
composer.lock
composerは、composer.jsonではなく、lockファイルに従ってインストールを行う。
という事で、lockファイルをちゃんと作り直して実行。
めでたく、composerが成功し、ローカルにあるパッケージでLaravelアプリケーションが無事動き出してくれたとさ。
備考
- コンテナビルド時には、cacheを使ってビルドする事もあるので、その時はno-cacheを指定して行う
- 古いパッケージを使うのは良くない。ちゃんとメンテナンスして、フレッシュな状態を保ちましょう。（自戒。近いうちに検討します・・・・）