You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The assumption here is that --all-features is additive, and so contains a cache sufficient for --no-default-features and the default feature set. The save-if option allows the workflow to guarantee that the stored cache is the --all-features one, which should be sufficient for the other feature sets, and not racing differently populated caches against each other.
The alternative is to split the cache initialization into a separate job, something like
and while this will ensure that the initial cache population run will have all of the test matrix jobs restore from cache, it requires undesirable duplication of the tests job and thus
on initial cache-population run, builds local tests and discards that work; and
on subsequent fresh-cache runs, still has to initialize and restore from cache before starting test jobs.
(If feature selection of the local crate changes which dependencies are selected upstream, this cache sharing will be ineffective and a pessimization on runtime. Perhaps that's reason enough to not encourage it. But it still does reduce the amount of cache significantly over caching each featureset independently.)
Implementation-wise, this should just amount to an early-out in save.ts when !core.getBooleanInput("save-if").
More generally, this usecase would be well served by a jobs.<job-id>.continues-from: <job-id> (so long as it manages to respect a matrix-keyed runs-on) but that seems unlikely to get from upstream. (It would also require making sure that cache saving is idempotent and doesn't trash local state.)
The text was updated successfully, but these errors were encountered: