Support Incremental Builds by not re-publish a container if nothing's changed

[afscrome]

If you run dotnet publish /t:PublishContainer on a project that hasn't changed since the last container publish, the SDK will build a new image, even though nothing's changed

Repro Steps

1. Run dotnet publish /t:PublishContainer
2. Run dotnet publish /t:PublishContainer a second time, without making any other code changes

Expected Results

The second (and subsequent) publish command shouldn't build a whole new container until something else has changed

Actual Results

The second (and subsequent) commands build a new image - note how in the below example the image id has changed between the two publishes.

$> dotnet publish app /t:PublishContainer

  Determining projects to restore...
  All projects are up-to-date for restore.
  Sample -> C:\src\ACTest\artifacts\bin\Sample\Sample.dll
  Sample -> C:\src\ACTest\artifacts\publish\Sample\
  Building image 'actest/myapp' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/aspnet:8.0'.
  Pushed image 'actest/myapp:latest' to local registry via 'docker'.

$> docker images actest/myapp
REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
actest/myapp   latest    7bef4d40e5d3   4 seconds ago   221MB

$> dotnet publish app /t:PublishContainer

  Determining projects to restore...
  All projects are up-to-date for restore.
  Sample -> C:\src\ACTest\artifacts\bin\Sample\Sample.dll
  Sample -> C:\src\ACTest\artifacts\publish\Sample\
  Building image 'actest/myapp' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/aspnet:8.0'.
  Pushed image 'actest/myapp:latest' to local registry via 'docker'.

$> docker images actest/myapp
REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
actest/myapp   latest    7c293a165f4d   5 seconds ago   221MB

[baronfel]

Excellent report, thanks for writing it.

There are two main sources of incrementality failures that I see today that would need to be addressed:

• The Task works directly on the $(PublishDir), but for incrementality tracking purposes we should be depending on the specific files inside this directory (so in MSBuild terms an Item with an Include of $(PublishDir)/**/*.*
• The other major inputs need to be captured in a file that could be written to the intermediate output directory for incrementality purposes:
  • Base image SHA
  • ENV directives
  • Labels/annotations
  • USER
  • WORKDIR
  • CMD/ENTRYPOINT

[afscrome]

Incremental checks on Labels would need to ignore the ContainerGenerateLabelsImageCreated labels that get defaulted to the current time. Or perhaps there we can use another more stable date that can be used (e.g. the LastModifiedDate of the entry point file)

[baronfel]

Correct, that would overlap with the determinism concerns that we were talking about in another, separate issue