Repository navigation
Conversation
When a task runs on a different worker-type, the underlying environment could be completely different. Or not. It could be a simple instance type change that has no impact on the task's artifact, or it could be a different OS, a different cloud provider or even a different worker binary. Therefore it's best to include the worker-type in the cached task digest.
|
For context, this was made to prevent bustage like: Which happened because: Switched the |
bhearsum
left a comment
There was a problem hiding this comment.
I have mixed feelings on this. There are many changes to worker-type that do not affect the cache digest (ie: changing from a small to a large instance). There can also be changes to worker images that do not change the worker type that do affect the cache digest.
On balance, I think this is safe the option, but it's unclear how much it's going to cost in cached task rebuilding, and how much more often it will cause us to do so at inconvenient times (eg: when uplifting patches around an urgent release).
Because this is easy to revert if we change our mind, I'm approving, but I wanted to voice those potential concerns.
|
There's no rush to land this, we can debate a bit. |
When a task runs on a different worker-type, the underlying environment could be completely different. Or not.
It could be a simple instance type change that has no impact on the task's artifact, or it could be a different OS, a different cloud provider or even a different worker binary.
Therefore it's best to include the worker-type in the cached task digest.