Can a dependency cache cause incorrect builds?

[Geoff Clayton]

We have recently had an issue where a new feature was deployed but did not work on the live UAT environment despite being fine in local dev. 

By running client console commands we were able to see that a recently upgraded package was running as the old version in UAT but not locally. This was the root cause of the bug. 

Our app's pipeline uses the generic 'node' cache. Deleting this cache manually from the Pipelines UI led to the build completing correctly (same client console command now indicates the correct package version is deployed to production). 

If this is all as it seems to be then this seems to be a very dangerous situation. In this case it was obvious there was a problem but more subtle bugs may not be detected so easily in UAT. 

If it is indeed best practise to clear caches manually when dependencies change then it seems to me that a logical extension to this would be to link a cache to one or more files (i.e. node cache would be linked to `package-lock.json`) and if the linked file changes have the Pipeline clear the cache at the start. 

I feel though that I must have missed something here as I would expect the above to cause plenty of problems for people if it is the expected behaviour. 

[Tom Bradshaw · Accepted solution]

Hi @Geoff Clayton

This sounds like a useful feature. Would you be able to raise a feature request at https://bitbucket.org/site/master/ and include as much detail as you can about the way you would want this to work.

Unfortunately at the moment this feature does not exist in pipelines. The workaround is what you've been using so far; deleting the cache manually when dependencies change.

If you have any more questions let me know.

Cheers,

Tom.

[Geoff Clayton]

Here is the feature request: https://bitbucket.org/site/master/issues/18992/implement-automated-dependency-cache