[Feature] Support a Docker only build strategy without specifying a language

[sabbour]

Today, it looks like the language property is required. For builds that are purely docker build that deploy the containers on targets like containerapps and aks, why does this even matter? I don't want to have the build dependencies on my machine. This should also open up supporting any project as long as a Dockerfile exists.

services:
    frontend:
        project: ./src/frontend/code
        language: js # why do we need this?
        host: aks 
        k8s:
          deploymentPath: ../manifests

[vhvb1989]

It makes sense to ignore language for container apps or aks. But, at the same time, azd can help to launch applications locally (currently with a little contribution from VSCode). There is a command azd restore used by VSCode to install all application's dependencies (which is different for each language), so the language is how azd know how to do this.

I also see a model where, if my application is using containers, I might want to start the containers locally to run my app, instead of running the application directly, but we don't have the end-2-end experience to support this for azd (from restoring, building and debugging your app using containers).

The current templates we have for containers are only using the containers as a way to deploy the app to Azure, but when running locally (for debugging, for example), the container is not used.

[rajeshkamal5050]

Moving it to Backlog @savannahostrowski @ellismg

[heaths]

Why is services.*.language even required? I can't specify "rust" or "go" (or "rustlang" or "golang") without validation failures. Even if you do use this property, can't you simply ignore whatever behavior you do if it's not supported and allow devs to specify any language?

Based on context above, I still don't understand how it's used, though. With most editors you just open the folder e.g., VSCode, Xcode, etc. Even Visual Studio most often works great opening just a folder (as long as .NET projects use SDK-style projects).

[vhvb1989]

@heaths , azd is currently blocked from removing the language because it is required for azd restore and azd build commands.
When you are working with container apps, azd will: azd restore -> use the language to know how to do restoring. For example, for dotnet, azd calls dotnet restore azd build -> similar to restore, azd will build locally (w/o the dockerfile) azd package -> here's where azd would finally use the dockerfile to create a container image

Ideally, we would want to remove the language for ACA and maybe make restore and build a no-op. Or use build for docker build...

However, that's something pending to be addressed and blocking the removal of the language.

As a user, you can currently choose any language and as long as you dont run azd build or azd restore you will be OK and you can use Rust, Go, or any other language. You would take control of it with your dockerfile.

@wbreza

[heaths]

That doesn't explain why the schema requires it when only 2 of many commands require it. It should be optional, and those subcommands should err when it's not defined. language clearly isn't required in all use cases, ergo it's not required. This is blocking legitimate use cases by gatekeeping what languages can be used.

At the very least, you could make it an open enumeration - like our extensible enums we default to for Azure REST APIs' enums. /cc @ellismg