如何在GitHub操作中缓存步骤? [英] How do I cache steps in GitHub actions?

查看:137
本文介绍了如何在GitHub操作中缓存步骤?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

说我有一个包含两个步骤的GitHub动作工作流.

  1. 下载并编译应用程序的依赖项.
  2. 编译并测试我的应用程序

我的依赖项很少更改,并且可以安全地缓存已编译的依赖项,直到下次更改指定其版本的锁定文件为止.

是否可以保存第一步的结果,以便将来的工作流可以跳过该步骤?

解决方案

缓存现在通过缓存操作.它可以跨存储库中的作业和工作流工作.另请参见:以下示例:

name: GitHub Actions Workflow with NPM cache

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1

    - name: Cache NPM dependencies
      uses: actions/cache@v1
      with:
        path: ~/.npm
        key: ${{ runner.OS }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.OS }}-npm-cache-

    - name: Install NPM dependencies
      run: npm install

cache操作的pathkey参数用于标识缓存.

可选的restore-keys用于可能的回退到部分匹配(即,如果package-lock.json更改,将使用以前的缓存).

在使用restore-keys后备并且存在多个不同的缓存(例如JS包和系统包)的情况下,使用某些ID(在本示例中为npm-cache)为键添加前缀非常有用.否则,一个缓存可能会回退到另一个不相关的缓存.同样,在使用矩阵构建时,操作系统前缀很有用,这样就不会混淆不同系统的缓存.

您还可以使用 @ actions/cache 构建自己的可重复使用的缓存逻辑,例如:


旧答案:

当前无法进行本地缓存, 1 在所有工作流程中均无效.

Say I have a GitHub actions workflow with 2 steps.

  1. Download and compile my application's dependencies.
  2. Compile and test my application

My dependencies rarely change and the compiled dependencies can be safely cached until I next change the lock-file that specifies their versions.

Is a way to save the result of the first step so that in future workflow can skip over that step?

解决方案

Caching is now natively supported via the cache action. It works across both jobs and workflows within a repository. See also: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/caching-dependencies-to-speed-up-workflows.

Consider the following example:

name: GitHub Actions Workflow with NPM cache

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1

    - name: Cache NPM dependencies
      uses: actions/cache@v1
      with:
        path: ~/.npm
        key: ${{ runner.OS }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.OS }}-npm-cache-

    - name: Install NPM dependencies
      run: npm install

Where the path and key parameters of the cache action is used to identify the cache.

The optional restore-keys is used for a possible fallback to a partial match (i.e. if package-lock.json changes the previous cache will be used).

Prefixing the keys with some id (npm-cache in this example) is useful when the restore-keys fallback is used and there're multiple different caches (e.g. for JS packages and for system packages). Otherwise, one cache could fall back to the other unrelated cache. Similarly, an OS prefix useful when using matrix builds so caches of different systems don't get mixed up.

You can also build your own reusable caching logic with @actions/cache such as:


Old answer:

Native caching is not currently possible, expected to be implemented by mid-November 2019.

You can use artifacts (1, 2) to move directories between jobs (within 1 workflow) as proposed on the GH Community board. This, however, doesn't work across workflows.

这篇关于如何在GitHub操作中缓存步骤?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆