Closed martinmiglio closed 1 year ago
Does the action also prune cache ever, or will it let things grow indefinitely?
Does the action also prune cache ever, or will it let things grow indefinitely?
action/cache
has its own eviction policy, essentially removed after 7 days if unused or if storage is full.
New caches are created with each run and subsequent runs should prefer them over older ones, so the old ones will get dropped off eventually.
Would it be a good idea to include an option to enable/disable the cache? If so what should be the default behavior? @kayhayen
That's great. I have people who insist on never using caches, because these can be bug introducing/hiding. The default however should be yes, just like with Nuitka. There is a Nuitka option --disable-ccache
(old one, going to hide it eventually) which I guess, we could piggy back for that purpose. The real one to expose is of course --disable-cache=ccache
, so that should be how to control things.
To expose --disable-cache=ccache
I added an input to the action called disable-cache
.
It will pass through whatever the option is to Nuitka with --disable-cache:${{ inputs.disable-cache }}
.
If that option is set to ccache
, the apt-get step won`t get run
Ok, that's good enough for now. I probably would prefer a generic cache option, that gives control over all the caches, but we can do that later. Thanks, good job.
Using
actions/cache@v3
, the artifacts from the Nuitka build process can be shared between workflow runs.This PR adds steps to the workflow which:
ccache
on Linux using apt-get. This step is skipped on macOS and Windows because Nuitka installsccache
on those platforms.Things to note:
actions/cache
is setup to restore caches prioritizing this action's latest commit SHA, the python version, then the runner's operating system.