-
-
Couldn't load subscription status.
- Fork 144
Description
The action will run pnpm store prune as a post action, but based on the documented example for caching as in README:
on:
- push
- pull_request
jobs:
cache-and-install:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
name: Install pnpm
with:
version: 10
run_install: false
- name: Install Node.js
uses: actions/setup-node@v4
with:
node-version: 20
cache: 'pnpm'
- name: Install dependencies
run: pnpm installThe caching step in the post step of action/setup-node will actually happen before the post step pnpm/action-setup which does the pruning, so the cache will not be pruned.
If you try to still benefit from the pruning in this aciton, and put any caching before pnpm/action-setup (so that the post caching happens after action-setup post), you won't benefit from the cache as the install step of this action nukes the install directory. Doing caching before pnpm is installed also means that you cannot get pnpm store path to get what directory to cache.
Workaround
To cache the pnpm store, after pruning, you could something like this
on: [push, pull_request]
jobs:
cache-and-install:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
name: Install pnpm
with:
version: 10
run_install: false
- name: Install Node.js
uses: actions/setup-node@v4
with:
node-version: 20
- name: Get pnpm cache directory
id: pnpm-store-path
run: echo "path=$(pnpm store path)" >> $GITHUB_OUTPUT
- name: Cache pnpm store
uses: actions/cache@v4
with:
path: ${{ steps.pnpm-store-path.outputs.path }}
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-store-
- name: Install dependencies
run: pnpm install
- name: Prune store
run: pnpm store pruneSuggestion
I think it would be great if pnpm/action-setup had built-in cache, especially since with the devEngines.runtime support, you don't really need to use setup-node anymore. That seems like quite the effort, and not sure something I could pull off, so what's easier to achieve would be to remove the pruning from the post action, and update the documentation to recommend to run it separately. I will try to see if I can put together a PR with this.
EDIT: Or, the pruning could happen right after install I guess! That should not have any negative effect on any following actions, but any caching that may happen later will be caching a pruned store at least?