Dockerfiles aren't rebuilt when there are changes to dependent Dockerfiles

[sbomer]

There seems to be some problem with the caching logic. Touching a Dockerfile causes it to be rebuilt, but in some cases images that depend on the rebuilt one don't get rebuilt. Context from dotnet/dotnet-buildtools-prereqs-docker#1313:

when I added LoongArch in this file and touched cross/loongarch, it didn't located the new architecture. It required us to also touch crossdeps-llvm

@mthalman is this expected? I would have thought that if I touch crossdeps-builder, images which depend on it (like crossdeps-llvm) would get rebuilt too. This seems like it might be a bug.

I suspect it is related to the use of multistage dockerfiles. Maybe the caching logic only checks the base image of the last stage here:

docker-tools/src/Microsoft.DotNet.ImageBuilder/src/ImageCacheService.cs

Lines 153 to 169 in b8c26b6

	private async Task<bool> IsBaseImageDigestUpToDateAsync(
	PlatformInfo platform,
	PlatformData srcPlatformData,
	ImageDigestCache imageDigestCache,
	ImageNameResolver imageNameResolver,
	bool isLocalImageExpected,
	bool isDryRun)
	{
	_loggerService.WriteMessage();
	if (platform.FinalStageFromImage is null)
	{
	_loggerService.WriteMessage($"Image does not have a base image. By default, it is considered up-to-date.");
	return true;
	}
	string queryImage = imageNameResolver.GetFinalStageImageNameForDigestQuery(platform);

Related: #1270

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[mthalman]

This seems like a duplicate of #1516. That had been fixed and buildtools-prereqs does have version of ImageBuilder with the fix. This requires further investigation.

[sbomer]

Also found #1455 which looks like the same issue. It was closed as not planned - could we reevaluate given that we keep hitting this?

[lbussell]

Also found #1455 which looks like the same issue. It was closed as not planned - could we reevaluate given that we keep hitting this?

@sbomer Yes, if it is causing significant pain, feel free to re-open #1455. Or I can if you don't have permission.

[sbomer]

Thanks! I don't have permission - if you reopen that we can close this one as a duplicate.