在GitHub操作中，缓存应该出现在哪里？ [英] Where should caching occur in a GitHub Action?

问题描述

caching in a GitHub Action的正确位置是什么？是否特别正确地将其放置在使用其他操作运行工具设置之前或之后？

例如，如果我是using somethingLikehaskell/actions/setup，我应该在这之前还是之后使用actions/cache？换句话说：如果setup随后在My Action的未来运行中安装更新的组件，缓存的相应部分是否会失效？

推荐答案

缓存操作应放在消耗或创建该缓存的任何步骤之前。此步骤负责：

1. 定义缓存参数。
2. 正在还原缓存(如果它是过去缓存的)。

GitHub操作随后将在所有步骤之后运行"；Post*"；步骤，该步骤将存储缓存以备将来调用。

请参阅documentation中的示例工作流。

例如，考虑以下示例工作流：

name: Caching Test

on: push

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Enable Cache
      id: cache-action
      uses: actions/cache@v2
      with:
        path: cache-folder
        key: ${{ runner.os }}-cache-key

    - name: Use or generate the cache
      if: steps.cache-action.outputs.cache-hit != 'true'
      run: mkdir cache-folder && touch cache-folder/hello

    - name: Verify we have our cached file
      run: ls cache-folder

第一次运行时的外观如下：

这是它在第二次运行时的外观：

GitHub不会使缓存无效。相反，开发人员有责任确保缓存键对于它所代表的内容是唯一的。

通常的做法是设置缓存键，使其包含存储库中某个文件的散列，这样对该文件的更改将生成不同的缓存键。这种行为的一个很好的例子是，当您拥有列出所有存储库依赖项的锁文件时(requirements.txt对于pyrhon，Gemfile.lock对于ruby等等)。

这是通过类似如下的语法实现的：

key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

如文档的Creating a cache key部分所述。

这篇关于在GitHub操作中，缓存应该出现在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！