2ステップのGitHubアクションワークフローがあるとします。
私の依存関係はめったに変更されず、コンパイルされた依存関係は、バージョンを指定するロックファイルを次に変更するまで安全にキャッシュできます。
最初のステップの結果を保存して、将来のワークフローでそのステップをスキップできるようにする方法はありますか?
2つのオプションを要約します。
ワークフローにコマンドを追加して、ディレクトリをキャッシュできます。そのステップに到達すると、指定したディレクトリが以前に保存されているかどうかがチェックされます。もしそうなら、それをつかむでしょう。そうでなければ、それはしません。次に、次のステップで、キャッシュされたデータが存在するかどうかを確認するチェックを記述します。たとえば、大きくてあまり変化しない依存関係をコンパイルするとします。ワークフローの最初にキャッシュステップを追加し、そこにない場合はディレクトリのコンテンツを構築するステップを追加できます。初めて実行するとファイルは見つかりませんが、その後はファイルが見つかり、ワークフローがより速く実行されます。
バックグラウンドで、GitHubがディレクトリのZipをgithub自身のAWSストレージにアップロードしています。 1週間より古いものや、2 GBの制限に達した場合は削除されます。
この手法のいくつかの欠点は、ディレクトリのみを保存することです。したがって、/ usr/binにインストールした場合は、それをキャッシュする必要があります。それは扱いにくいでしょう。代わりに$ home/.localにインストールし、echo set-envを使用してパスに追加する必要があります。
Dockerはもう少し複雑です。つまり、Dockerhubアカウントを持ち、2つのことを管理する必要があります。しかし、それははるかに強力です。ディレクトリだけを保存する代わりに、コンピュータ全体を保存します!何をするかは、apt-getやpython pip linesや長いコンパイルなど)のようなすべての依存関係を含むDockerfileを作成します。次に、そのDockerイメージをビルドして公開します最後に、ubuntu-latestなどではなく、新しいdockerイメージでテストを実行するようにテストを設定します。これからは、依存関係をインストールする代わりに、イメージをダウンロードします。
そのDockerfileをプロジェクトと同じGitHubリポジトリに保存し、最新のDockerイメージをダウンロードし、必要に応じて変更された手順だけを再構築し、Dockerhubにアップロードする手順を含むジョブを記述して、これをさらに自動化できます。そして、それを「必要」とし、画像を使用するジョブ。このようにして、ワークフローは、必要に応じてDockerイメージを更新し、それを使用します。
欠点は、depが1つのファイル、Dockerfile、およびワークフロー内のテストに含まれるため、すべてが一緒になるわけではないことです。また、イメージをダウンロードする時間が依存関係を構築する時間よりも長い場合、これは適切な選択ではありません。
それぞれに長所と短所があると思います。キャッシングは、.localへのコンパイルなど、本当に単純なものにのみ適しています。より広範なものが必要な場合は、Dockerが最も強力です。