Today when we have to build a service (e.g. during the soon to be added package) we use the language of the service to inform what command we run.

For example, for a dotnet service, we run dotnet publish -c Release --output <an-intermediate-path-that-azd-creates> to build a release version of their application into a temporary folder.

We make similar decisions for the user in other app specific gestures like restore.

For all these cases, we should allow the user to override this behavior on a per service basis.

One possible approach is adding something to azure.yaml for a service like this:

services:
  api:
    language: dotnet
    host: appservice
    package: dotnet build -c Release /p:SomePropertyThatIsVeryImportantToMeForMyApp=true --output ${AZD_PUBLISH_ROOT}

In the above, a user can provide whatever command they want (and we provide a way to flow some AZD specific information, like where the output of the build should go, via substitutions like ${AZD_PUBLISH_ROOT}).

This would give the user full control over what is happening for cases where our defaults are wrong for their scenario.

When we do this, we should think about how this relates to a "none" language (or the concept of using azd to manage a service where azd does not have intrinsic knowledge of the toolchain (e.g. golang, today)