настройка-узел восстанавливает кеш, но все еще требует времени для пряжи

#github-actions #yarnpkg

#github-действия #yarnpkg

Вопрос:

Таким образом, действие setup-node github кэширует node_modules с помощью этой конфигурации:

       - uses: actions/setup-node@v2
        with:
          node-version: '14.15.5'
          cache: 'yarn'
 

Я вижу, что он восстанавливает кеш.

 /home/runner/.cache/yarn/v6
Received 0 of 138278798 (0.0%), 0.0 MBs/sec
Received 113246208 of 138278798 (81.9%), 53.4 MBs/sec
Received 138278798 of 138278798 (100.0%), 55.8 MBs/sec
Cache Size: ~132 MB (138278798 B)
/usr/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/b44b9064-7157-4afd-a342-f81e1005ef1d/cache.tzst -P -C /home/runner/work/app-frontend/app-frontend
Cache restored successfully
 

Но когда я делаю yarn --frozen-lockfile (мы всегда фиксируем наши файлы блокировки)

Я вижу этот вывод:

 Run yarn --frozen-lockfile
yarn install v1.22.17
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
...
 

и этот шаг по-прежнему занимает 44 секунды.

Я не понимаю, почему это происходит.

Я реализовал свое собственное кэширование следующим образом:

       - name: Cache Modules
        uses: actions/cache@v2
        with:
          path: '**/node_modules'
          key: ${{ runner.os }}-modules-${{ hashFiles('**/yarn.lock') }}
 

И теперь, когда я запускаю yarn --frozen-lockfile шаг, он завершается через 3 секунды и выводит:

 Run yarn --frozen-lockfile
yarn install v1.22.17
[1/4] Resolving packages...
success Already up-to-date.
Done in 1.21s.
 

Я не понимаю, почему это так. Очевидно, я что-то недопонимаю в том, как что-то (пряжа, кэширование узла настройки, что-то еще?) работает.

Цель состоит в том, чтобы выполнить сборку как можно быстрее (при этом, конечно, корректно). Кто-нибудь может помочь мне понять, почему setup-node восстанавливает кеш, но yarn все еще выполняет работу за 44 секунды?

Комментарии:

1. Что заставляет вас думать, что он восстанавливает кеш? Что, если он устанавливает зависимости? Кстати. из cache-hit задачи выводится setup-node сообщение о том, был ли это кеш-хит.

2. @rethab смотрите мое редактирование. Я также никогда не хочу «пропускать» yarn --frozen-lockfile CI, чтобы проверить правильность файла блокировки, который находится в репозитории.

Ответ №1:

Встроенный кэш setup-node помещает установленные пакеты в глобальный кэш для используемого менеджера пакетов (yarn или npm). Пакеты все равно нужно будет разрешить и установить из глобального кэша в локальный рабочий каталог, что в моем случае все равно заняло 44 секунды.

С другой стороны, мой кэш кэшировал локальные пакеты рабочего каталога, поэтому они уже были установлены и разрешены локально, когда я запустил его во второй раз.