Repository navigation
v2.0.0
setup-pkgproxy is now a Node.js action that saves the package cache itself at the end of the job (#1). Using it takes one step:
on:
push:
branches: [main] # only the default branch saves the cache, see below
pull_request:
# ...
- uses: zyga/setup-pkgproxy@v2
id: pkgproxyUpgrading from v1 (details in the README's "Upgrading from v1"):
- Delete your "Prepare pkgproxy cache for saving" and
actions/cache/savesteps. A post step stops pkgproxy and saves the cache, whether the job passed, failed or was cancelled. - Only the default branch saves the cache, by default (
save-package-cache: default-branch | always | never). Pull requests and other branches restore the default branch's cache, but never save their own: a PR's copy would only help that PR, while taking room (several hundred MB per snap build) that would evict the default branch's. If your workflow runs only onpull_request, add apushtrigger for the default branch, or nothing is ever saved. - Outputs:
package-cache-hit,package-cache-key-successandpackage-cache-key-partialare replaced bypackage-cache-restored-keyandpackage-cache-key.
How the cache is kept:
- Rolling keys: each job that adds to the cache saves it under a key of its own, and the next job restores the newest one, so the cache keeps up with what your jobs download instead of freezing at its first save.
- No needless uploads: a job that added nothing saves nothing.
- xattrs preserved: the cache is saved as an archive made with
tar --xattrs, ready for pkgproxy 0.12, underpkgproxy-cache-v4, the same format and prefix as v1.2.0. A v1.2 cache warms v2, but caches from v1.0 and v1.1 start cold once. - Job summary: shows what was restored, how the cache grew, whether it was saved and why, and
pkgproxyctl stats.
Also:
- pkgproxy v0.11.0.
- Go: taken from the runner's tool cache, or downloaded from go.dev and checked against its SHA-256.
- Clean checkout: the built binary is cached outside your checkout.
v1 stays maintained on releases/v1 (v1.2.0 is out alongside this release).