Build avoidance mechanism

[Brawdunoir]

Is your feature request related to a problem? Yes. Especially in CI environment, the build avoidance mechanism fails because of Dockerfile or build context.

Which solution do you suggest?

1. Use paths relative to the project in order to calculate the two different hash.
2. Compute the checksum of Dockerfile rather than a combination of mTime and size.

Overall, from what I saw in the code base, I feel like the two functions Directory and DirectoryExcludes in pkg/util/hash should call each other, in order to get a consistent way of hash (and Directory could get its own fast bool arg).

Moreover, the path of a Dockerfile should not impact at all its hash.

Which alternative solutions exist? Add a CI flag in the code to change some mechanism like the build avoidance.

Additional context My CI environment (on GitlabCI) have been changing path depending on the runner. Whereas some configuration on my side have mitigated this issue, I think Devspace’s cache should not have been broken by an absolute path. Also, by default, pulling a repository changes the mTime on all the code base, thus invalidating Dockerfile hash. Even if this can be mitigated by some tricks, having Devspace implementing this by default could be great.

Using checksum and relative path by default for both Dockerfile hash and build context hash could be great (and maybe moving the fast boolean in the devspace.yaml configuration).

Thanks again for this awesome project. I am open to create a PR after some discussion

[Brawdunoir]

I see there is not that much involvement on this issue. But it creates important issue for our use case right now. Within our CI, we need to fix Dockerfile’s timestamp in order not to trigger shouldRebuild() function, due to this function internal mechanism.

I understand the complexity of the function and that a simple workaround on our side might not be the best long-term solution. Therefore, I'm considering the possibility of submitting a Pull Request that would improve the shouldRebuild() function.

However, given the multiple potential approaches to address this problem, I believe it would be beneficial for all if we could first discuss the possible implementations. This way, we can ensure that any changes align well with the overall design and do not unintentionally affect other parts of the project.

Looking forward to your thoughts on this.

Thanks.