Saving cache on job failure in GitHub Actions

I am using the GitHub cache action, but I noticed that the no cache will be created if the job fails. From the docs:

If the job completes successfully, the action creates a new cache with the contents of the path directory.

A stripped down version of my workflow YAML file:

name: Build

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v1

      - name: Setup Node.js
        uses: actions/setup-node@master
        with:
          node-version: '10.x'

      - name: Get yarn cache path
        id: yarn-cache-dir-path
        run: echo "::set-output name=dir::$(yarn cache dir)"

      - name: Restore yarn cache
        uses: actions/cache@v1
        id: yarn-cache
        with:
          path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: Install yarn dependencies
        run: yarn install

      - name: Build
        run: yarn build

I noticed that if my Build step fails the cache post-step will be skipped unnecessarily, which causes the installed dependencies to not be cached. This requires subsequent runs to download dependencies again, slowing down the job.

Is there a way to always cache the dependencies, even when the build step fails?

You can now use the actions/cache/save action to save the cache right after it is populated, and before any tests (or anything that might fail the job) runs. This is how issue actions/cache#92 was resolved in the end.

steps:
  - uses: actions/checkout@v3
  .
  . // restore if need be
  .
  - name: Build
    run: /build.sh
  - uses: actions/cache/save@v3
    if: always() // or any other condition to invoke the save action
    with:
      path: path/to/dependencies
      key: ${{ runner.os }}-${{ hashFiles('**/lockfiles') }}

https://github.com/actions/cache/tree/main/save#always-save-cache

cache@v4 added save-always parameter

This functionality however appears to be broken, currently.