Emit dockerfile.v0 resource in manifest.

[mitchdenny]

Fixes #769

This PR adds an extension method to executable resource builders which flags that when emitted to the manifest they should be emitted as a dockerfile.v0 resource.

• Basic emission logic for dockerfile.v0
• Unit tests for manifest publishing
• Remove changes made to sample (just used for illustration purposes, won't be merged)

Given the following code:

var builder = DistributedApplication.CreateBuilder(args);

builder.AddAzureProvisioning();

builder.AddNpmApp("nodeapp", "..\\nodeapp")
    .WithServiceBinding(5555, scheme: "http", env: "PORT")
    .WithDockerfile();

The following manifest snippet will be produced:

{
  "resources": {
    "nodeapp": {
      "type": "dockerfile.v0",
      "path": "..\\nodeapp\\Dockerfile",
      "context": "..\\nodeapp",
      "env": {
        "NODE_ENV": "development",
        "PORT": "{bindings.http.port}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "containerPort": 5555
        }
      }
    }
}

[mitchdenny]

@ellismg and @rajeshkamal5050 for thoughts on this from the AZD perspective.

[davidfowl]

Since we're making bigger API changes I think we should make more to set out selves up for a better future:

1. Expose an extension method that adds the ManifestCallbackAnnotation (if we had that we could avoid the break here)
2. The ManifestPublisherContext should have the manifest output path as context
3. We should consider flowing the resource itself to the ManifestPublisherContext (closures feel sorta bad).

[prom3theu5]

Added support for the dockerfile component to Aspir8 based on the above manifest entry. Will run through some tests over next few days - and follow this PR to see if there are any changes.

Atm - i've implemented it using the ContainerRegistry setup during the init command, along with resource name and latest tag on each build.
Tag will be made customizable though, and container registry overridable as a cli option - just not today, i'm a busy bee today 😛

[mitchdenny]

i'm a busy bee today 😛

Appreciate everything you are doing truly. You're making an awesome contribution to the project.

[mitchdenny]

2. The ManifestPublisherContext should have the manifest output path as context

It is ... check the ManifestPath property.

3. We should consider flowing the resource itself to the ManifestPublisherContext (closures feel sorta bad).

Not sure how I feel about this. If we go down this route I'll need to rework the callback methods (fine) but the very first thing I'll need to do on each of those callback methods is cast a non-generic IResource to the specific resource type that we are working within. I feel like the current capture approach is actually more ergonomic.

[DamianEdwards]

I'm not sure it's super clear that the .WithDockerFile() call only applies to the manifest. I look at that and think it's going to build and run a container when launched by the AppHost during local dev. Have we considered making it more explicit?

[mitchdenny]

I'm not sure it's super clear that the .WithDockerFile() call only applies to the manifest. I look at that and think it's going to build and run a container when launched by the AppHost during local dev. Have we considered making it more explicit?

Yeah I struggle with this too. The With verb doesn't quite work. I'm considering we do something like: AsDockerfileInManifest(...) but it seems a little too wordy? Thoughts?

[DamianEdwards]

Yeah I struggle with this too. The With verb doesn't quite work. I'm considering we do something like: AsDockerfileInManifest(...) but it seems a little too wordy? Thoughts?

You know what, I think I prefer that, or even WithDockerfileInManifest()

[mitchdenny]

I have a weakly held opinion that As is better than With in this case, but I don't want to introduce a new prefix unnecessarily.

[DamianEdwards]

I have a weakly held opinion that As is better than With in this case, but I don't want to introduce a new prefix unnecessarily.

Yep I totally see your point and I could see us adopting the As prefix for "transform" operations like this. Do what you feel is best for now 😄