Infinite loop of rebuilds for Image Builder

[mthalman]

AutoBuilder keeps thinking it needs to rebuild the Windows version of Image Builder. This is likely caused by #1814 with a related issue described in #1823. Not sure if #1823 fixes this issue too.

[lbussell]

Still a problem after #1823. Investigating

[lbussell]

In regards to #1823 and #1814, I think ideally we'd change the osVersion to represent the output image. But, the infra uses osVersion to determine the build matrix which breaks Windows version compatibility (for example the Server 2019 build image cannot build an image using the 2022 image). So that's why osVersion needs to be 2025 for all images.

Here's what happens (in this example build):

• After the platform-specific build leg, image-info.json correctly has 3 entries for windows:
  • windowsservercore-ltsc2016-amd64-2805337
  • nanoserver-1809-amd64-2805337
  • nanoserver-ltsc2022-amd64-2805337
• After the post-build step, image-info.json only has the nanoserver-ltsc2022 entry.
• post-build step runs MergeImageInfoCommand, which uses PlatformData and not PlatformInfo for comparison.
• So to fix the image info output, we need to accommodate for build args in PlatformData's CompareTo/GetIdentifier method as well.

[mthalman]

I agree that changing how osVersion works would be good. You're right about the build args. Even if osVersions was unique, you could theoretically have issues with platform merging due to the use of build args for other scenarios.

[lbussell]

Adding build args to PlatformInfo.GetIdentifier breaks the following tests:

• BuildCommandTests.BuildCommand_Caching
• BuildCommandTests.BuildCommand_Caching_SharedDockerfile_MissingSourceImageInfoEntry_DiffBuildArgs
• BuildCommandTests.BuildCommand_MirroredImages (2/4 scenarios)

We should revert #1814 for now to stop the rebuilds and come back to this later.

[lbussell]

This was mitigated by #1834 which reverts #1814.