We require Netlify Deploy Previews to pass before we allow PRs to merge. Lately, the netlify NPM cache has gotten stuck, and all our PRs need to have their netlify npm cache cleared so they can pass.
However, just clearing the cache is not enough, as retrying the build does not notify the PR, even if the build passes. We have to first clear the cache, wait till it passes, and then push a new commit to the PR. Otherwise, the PR status check remains ‘failed’
I noticed that the failed check is build on a specific commit ref
Couple of thoughts around this. Not sure if they will help, but let me know how things go in your testing:
I think you can skip the step of “clearing the cache before pushing a new commit to the PR”, just fyi - that should not be needed nor have any impact aside from wasting your time and build minutes.
retrying a build always builds from head; that’s how that feature works. The new commit is what’s needed to correlate that build to a commit.
So I think that it won’t be possible for us to notify GH about some specific commit, when we are building HEAD as that feature is intended to do.
Perhaps we could debug what is happening around your “NPM cache getting stuck”, since that sounds like a problem you could solve, that would prevent the need for this at all? If you wanted to link me to such a failed build, I’d be happy to take a look and advise, although not until next week since I’m about to be off until monday
Thanks for looking into this. To address your points:
We must clear the cache before each build because netlify’s node build process does not respect the package-lock.json, and the cache’s node_modules is out of date, causing build errors. This is itself an ongoing problem for us, and is documented in several places in this forum, for example https://answers.netlify.com/t/how-to-enforce-package-lock-json/39735
Prior to a month or two ago, retrying a failed deploy preview build would notify the PR branch. Now, if the retry passes, the PR status check continues to point to the old fashioned build, and the PR will remain blocked until an (unnecessary) commit is pushed. This adds unnecessary friction to our already overloaded review cycle.
Deploy previews are meant primarily to validate and preview PR builds, so I find it very surprising that you’d characterize this regression as intended behaviour.
You could also try the plugin at the end of the thread he linked - it should force the reinstall during build and the checks should then work: How to enforce package-lock.json - #29 by IanVS)
We must clear the cache before each build because netlify’s node build process does not respect the package-lock.json, and the cache’s node_modules is out of date, causing build errors. This is itself an ongoing problem for us, and is documented in several places in this forum, for example https://answers.netlify.com/t/how-to-enforce-package-lock-json/39735
We’ve recently deployed a change behind a feature flag which removes our “skip” logic for npm install, making sure we always run it and leaving it up to the tool to work with the given lockfile and node_modules and decide what needs to be installed - chore: run pre & post install scripts by jobala · Pull Request #854 · netlify/build-image · GitHub. While this is still being rolled out (it isn’t at 100% yet) we can enable it for your account if you want (we’ll need some account info, like site/account name so that we can target your account).
If I understood your problem correctly I think that will likely fix it for you.
Prior to a month or two ago, retrying a failed deploy preview build would notify the PR branch. Now, if the retry passes, the PR status check continues to point to the old fashioned build, and the PR will remain blocked until an (unnecessary) commit is pushed. This adds unnecessary friction to our already overloaded review cycle.
We’ve recently fixed a bug in our system where we were performing misleading retries for builds. We lead customers to believe we were retrying builds for a particular commit when in reality we always build from HEAD. We’ve removed the misleading behaviour by making it clear we always build from HEAD when retrying builds. This however had the unintended consequence of breaking the behaviour for PR status checks for deploy previews. Since builds use the ref HEAD they no longer update the correct commit ref for the PR. This has been identified and we already have planned work to fix this (unfortunately we can’t really commit to a timeline since there’s a couple of moving pieces and we want to make sure we don’t cause further unintended breaking behaviour), but tl;dr we’re aware and we want to fix it
Sorry you’re having trouble with builds but hope this helps. Let us know if you need anything else and also if you want us to roll that feature flag for you. Thank you!
,
