Heya @bennypowers and welcome to our community!
I think you’ve correctly characterized the behavior shown here in our build-image:
which does this comparison:
…which has the basic effect you describe.
I don’t know of a way for you to accomplish that goal directly, but perhaps you could wrap the postinstall step in a conditional clause, since the error status returned to the shell is what causes the build to be marked as failed:
I don’t know what you can do in a postinstall script, but I’d guess it can be a shell script that you could catch that error on and self-clear the cache if you want to, or carry on without the patch (return 0 from the process even though patching failed), if you don’t need to do anything?
If you need to “do something” to fix things, such as say clearing your cache, you could from inside the script I describe, when you detect the patch system failing, choose to make an API call (you’ll want to set your API token as an environment variable in the UI to keep it safe and out of your public codebase: Netlify App) to the URL we use to trigger a build with cache cleared, before exiting the script with a non-zero status to terminate that build and allow the new one to start up.
What’s that API call?
with a body of
How’d I find it? Using this process: [Support Guide] Understanding and using Netlify's API
A better fix might be in the build image code; if you’d like to try a PR or file an issue, that repo is open and welcomes contributions and suggestions: GitHub - netlify/build-image: This is the build image used for running automated builds
If you do plan a PR, I’d still start with an issue filed there (feel free to ping back here with a link and we’ll make sure the team reviews ASAP!) and explain your plans so the team can review and ensure they think you’re working in a direction they can support, since we can’t merge a PR that breaks things for other customers and there may even be some works in progress that I don’t know about to support this already