The build cache is invalidated if things like the stack, Python version or (for pip users) therequirements.txt file contents changes. (Plus soon will also be invalidated if the package manager / package manager version changes: #1673 / #1674.)
Currently if the cache is invalidated only the first reason for invalidation is shown in the build logs, rather than all of the reasons.
This masks the fact that multiple changes might have occurred in the buildpack/app source/app config, which makes it harder to debug if a build fails as a result of one of the changes not mentioned, unless users directly compare to the build log of the last successful build.
For example if the stack and Python version changed at the same time, then currently only the stack is mentioned:
remote: -----> Stack has changed from heroku-24 to heroku-22, clearing cache
...which can lead to users blaming the stack upgrade for any failures, when it could also be due to the change in Python version.
The build cache is invalidated if things like the stack, Python version or (for pip users) the
requirements.txtfile contents changes. (Plus soon will also be invalidated if the package manager / package manager version changes: #1673 / #1674.)Currently if the cache is invalidated only the first reason for invalidation is shown in the build logs, rather than all of the reasons.
This masks the fact that multiple changes might have occurred in the buildpack/app source/app config, which makes it harder to debug if a build fails as a result of one of the changes not mentioned, unless users directly compare to the build log of the last successful build.
For example if the stack and Python version changed at the same time, then currently only the stack is mentioned:
...which can lead to users blaming the stack upgrade for any failures, when it could also be due to the change in Python version.