together, these allow us to perform a partial restore using an old cache (e.g. one where most of the AJ export files are still up-to-date).
the auto-exporter already reads last_exported_hashes.json and automatically determines what .ajblueprints it actually needs to re-export. it skips over up-to-date export files. this would decrease the auto-exporter time down from a few minutes to a few seconds (depending on how many .ajblueprint files were updated in a commit)
add a restore-keys field (without the hashFiles... suffix) to the actions/cache/restore parameters so it can partial restore old AJ export caches of the same Blockbench/Animated Java version
test the AJ export process speeds up when it needs to re-export only a few changed .ajblueprint files
a follow-up to https://github.com/TheAfroOfDoom/omega-flowey-minecraft-remastered/issues/81
the most common case of the AJ export cache becoming outdated will be when we update a relatively small amount of
.ajblueprintfiles.currently, the AJ exporter logic in CI (under the
datapack/testjob) will have to re-export every.ajblueprint, even if only a few actually changedwe can speed up this process significantly by utilizing our
last_exported_hashes.jsonlogic and the cache action'srestore-keysfield:together, these allow us to perform a partial restore using an old cache (e.g. one where most of the AJ export files are still up-to-date).
the auto-exporter already reads
last_exported_hashes.jsonand automatically determines what.ajblueprints it actually needs to re-export. it skips over up-to-date export files. this would decrease the auto-exporter time down from a few minutes to a few seconds (depending on how many.ajblueprintfiles were updated in a commit)TODO of this ticket is to:
last_exported_hashes.jsonto the AJ export cache paths in oursetup-animated-java-exportsCI actionrestore-keysfield (without thehashFiles...suffix) to theactions/cache/restoreparameters so it can partial restore old AJ export caches of the same Blockbench/Animated Java version.ajblueprintfiles