every time i edit a blog post or make a new one it has to rebuild the whole
blog, which is very stupid in my opinion, tried to implement caching
but quickly realised that netlify deletes all old deploy files
so my question is, is there any way to keep old deploy files so i could
implement a caching system ? i at least want to keep the b directory and
its children
my build times are relatively fast, but i only have 73 posts on there
and itll only grow and i really dont want to end up with large build
times in the future
by ‘deletes old deploy files’ i mean exactly what it says,
it deletes deletes old deploy files, all files that were present
previous deploy are not present in the current build
but yeah, thanks, although any other way without using functions ?
Wait, I think I know what you mean. I’m assuming, you’re saying that, in case of a manual deploy, when you upload a new deploy with a single file, the new deploy has only 1 file instead of all files from the previous deploy.
i dont do manual deploys, its all through git,
and youre off, let me explain
i just want to keep the old deploy files, your build/README.md at main · netlify/build · GitHub
solution is fine, but im wondering if theres a way to
make it work without using functions, maybe like
a mv b/ .cache/ ?
In the build system, the cache directory is /opt/build/cache where as the default base directory is /opt/build/repo.
Any content found in /opt/build/cache is automatically backed up after a successful build and restored at the start of a new build. All the developer needs to do is to make sure the build command is moving files to that directory after builds and restoring them from that directory at the start of new builds.
If I were doing this, I would write a bash script that does the following:
check to see if the directory in question exists in /opt/build/cache
if so, copy that to the working directory
run the build command
if the build command was successful, copy the directory in question back to /opt/build/cache
if the build was successful, return a zero exit code (which indicates a successful build to the build system)
if the build was not successful, return a non-zero exit code
You can do all that within a build command but putting all into a separate script and making that script the build command is a more pleasant developer workflow (for me at least).
If there are other questions or concerns, please let us know.