Azure / azure-dev

A developer CLI that reduces the time it takes for you to get started on Azure. The Azure Developer CLI (azd) provides a set of developer-friendly commands that map to key stages in your workflow - code, build, deploy, monitor, repeat.
https://aka.ms/azd
MIT License
402 stars 195 forks source link

[SWA] Add support for swa-cli.config.json #1953

Closed vhvb1989 closed 3 months ago

vhvb1989 commented 1 year ago

For deploying to SWA , azd takes the place of the classic SWA-CI-job which automatically builds the static web and publish it to Azure Static Apps.

When defining a service on azd, the path ./build within the service path is used by default to create the static app package. azd expects that the package operation will be placing the static page (html+js) into the build folder, where azd will take it and send it to Azure SWA.

Customers can change the build folder by adding dist: path to the azure.yml configuration, to define a different folder where the package is created.

However, there's not a way to tell azd what folder to use to package each language.
In case of .NET, azd calls dotnet publish to produce the application package, but dotnet uses /temp/xxxx to place the output, and not a folder within app/build. This means that as a customer, I can't set the dist value, as it will be different every time that the app is packaged.

For dotnet projects, there should be a way to set the output from dotnet publish so it can be deterministic and it can be set in the dist property from azure.yml. Or, even better, for dotnet projects, azd should use the path from /temp/xxx where the application is placed by dotnet and use it for deployment.

The current workaround to make this work is to set a prepackage hook and call dotnet publish -o some-path and then set dist: some-path. This will be making azd to call dotnet publish twice. The first time from the hook, with a deterministic path to used later for deployment, and a second time while azd does package for dotnet, which will ended up in some /temp/xxx folder and ignored for deployment.

Example:

services:
  frontend:
    project: ./app/frontend
    host: staticwebapp
    dist: ./build/wwwroot
    hooks:
      prepackage:
        shell: pwsh
        run: dotnet publish -o build
        continueOnError: false
        interactive: true

Sample repo: https://github.com/vhvb1989/net-blazor-swa

rajeshkamal5050 commented 1 year ago

Not a must-fix for GA. Adding it to backlog. Looks like we need to make build/packaging user configurable for different scenarios.

@savannahostrowski @ellismg

savannahostrowski commented 1 year ago

We should probably make this a general issue to honour whatever the config file is (I think staticwebapp.config.json?). Blazor is a key scenario for SWA so we do want to support this after GA. We should at least investigate what this would take during Gallium.

wbreza commented 1 year ago

We'll need to add support for swa-cli-config.json for better app dev/build time support. More info @ https://azure.github.io/static-web-apps-cli/docs/cli/swa-config

rajeshkamal5050 commented 1 year ago

This should also be impacting frameworks similar to Blazor which rely on swa-cli.config.json.

rajeshkamal5050 commented 1 year ago

Moving to Germanium @savannahostrowski

sinedied commented 6 months ago

Looking at the logs, the swa-cli-config.json is used when you're deployed a static web app with AZD if it's placed at the root of the project.

This can be used as a workaround, but it's also an issue when for example you have a function app that you want to deploy separately with AZD but use it with SWA to test the API locally, as it the function app will be deployed along the SWA if it's set up in the config.

What I think would be best is to ignore the config file entirely to avoid conflict and unwanted side effects (like the one I mentioned), but instead provide additional configuration options in azure.yaml to deploy a managed function alongside the SWA.

ankur198 commented 5 months ago

Hi @rajeshkamal5050 @wbreza @vhvb1989 @savannahostrowski. I understand it is not a priority right now but can you look into #3553. I have implemented a workaround. Would be great to know your thoughts.

Thanks in advance