3
ビルドにCMakeを使用する、大規模なマルチ言語プロジェクトがあります。これにはHaskellに書かれた部分があり、それにはstackを使ってビルドします。 CIビルドは、Gitlab CIによって処理され、ドッカーエグゼキュータで実行されます。ドッカー画像の作成中に、stack setupを使用してghcがダウンロードされます。ビルドのハスケル部分はまだビルドごとにすべての必要なパッケージをダウンロードしてビルドするので、かなり長い時間がかかります。私はGitlab CIのビルド間でスタックデータベースをキャッシュする
cache:
paths:
- src/utils/.stack-work
を追加したローカルデータベースをキャッシュに
（スタックYAMLファイルはsrc/utils/に住んでいる、と3つのHaskellのパッケージがあまりにもそこのdirsに住んでいます。）
これは本当にスピードアップしませんでしたビルドはそれほどです。もっと慎重にstack databasesを読んだ後、私はスナップショットがSTACK_ROOT（~/.stack）に入っていることに気付きました。スタックのオプションを検討すると、スナップショットをSTACK_ROOTとは別に保存するように指定する方法がないことが示唆されます。
Gitlab CIは、ビルドディレクトリ内の項目のキャッシュをのみを許可するように思われることを考えると、私は、私は2つのオプションが残っていると思う：ビルドディレクトリにSTACK_ROOTを配置し、全体をキャッシュする
- 使用
stack --stack-root <folder under build> ...もの。これは、私のキャッシュが100M未満から約1.6Gになることを意味します！ - 現在使用しているスナップショットをビルドに使用しているドッカーイメージにプリフェッチします。私の質問のために今
：？
- 私はスナップショット常にが
STACK_ROOTに格納されていることを考えるに修正アム stack setupがghcをフェッチする方法と同様に、特定のスナップショットをプリフェッチする方法はありますか？
私はまったく間違っているかもしれませんが、キャッシュサイズを制限するためのより良い方法があります。 @のDSIGNさんのコメントと私は満足のいくものであるソリューションに来ている思考のビットの後
ええ、あなたのプロジェクトで必要とされるパッケージをDockerイメージの一部にするのはどうですか？同様のセットアップを使用します：Gitlab-CI + Docker executor。しかし、我々はDockerイメージを作成する*ときにプロジェクトを一度構築します。このようにスタックには、すべての依存関係をダウンロードしてビルドするチャンスがあり、それらはドッカーイメージの一部として残されます。唯一の欠点は、スタックスナップショットを切り替えるとイメージを更新する必要があることです。 – dsign
「これは私が現在使用しているスナップショットをプリフェッチ」と呼ぶ方法の1つです:) 'stack setup'と同じくらい素敵なものが好きなだけでなく、選択されたスナップショットも引き寄せられます。私はスナップショットを頻繁に切り替えるわけではないので、私がしたときに画像を更新することはひどい負担ではありません...私もそれを避けることができるのは当然のことです。 – Magnus