SWA obscures underlying errors reported by StaticSitesClient

[jeremyvisser]

Describe the bug

When doing an swa deploy, errors executing StaticSitesClient are hidden from the output, even with --verbose=silly enabled.

This is related to something mentioned in passing in #615, but unlike that issue, I want this issue to focus on the errors being hidden as the bug being discussed, rather than whatever might be triggering the underlying error.

In my case, I had one of the same issues as #615 (I hadn't installed libicu, so StaticSitesClient was failing). However, I was stuck on this for quite a while because all I saw was:

$ npx @azure/static-web-apps-cli deploy --verbose=silly
[...]
Deploying using /home/user/.swa/deploy/53b7d0e07fe5c34bf68929fab92f87ce910288dc/StaticSitesClient@53b7d0e07fe5c34bf68929fab92f87ce910288dc
[...]
Deploying project to Azure Static Web Apps...
⠧ Preparing deployment. Please wait...

Not only was the output hidden, but it never timed out, even though the StaticSitesClient binary immediately crashed upon launch. The only way for me to see the error was manually invoking the (largely undocumented) client like so:

$ ~/.swa/deploy/53b7d0e07fe5c34bf68929fab92f87ce910288dc/StaticSitesClient 
Process terminated. Couldn't find a valid ICU package installed on the system. Please install libicu (or icu-libs) using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. Please see https://aka.ms/dotnet-missing-libicu for more information.
   at System.Environment.FailFast(System.String)
   at System.Globalization.GlobalizationMode+Settings..cctor()
   at System.Globalization.CultureData.CreateCultureWithInvariantData()
   at System.Globalization.CultureData.get_Invariant()
   at System.Globalization.TextInfo..cctor()
   at System.String.ToLowerInvariant()
   at System.Text.EncodingHelper.GetEncodingFromCharset()
   at System.ConsolePal.GetConsoleEncoding()
   at System.Console.get_OutputEncoding()
   at System.Console.CreateOutputWriter(System.IO.Stream)
   at System.Console.<get_Out>g__EnsureInitialized|26_0()
   at System.Console.WriteLine(System.String)
   at StaticSitesClient.Program.Main(System.String[])
Aborted (core dumped)

I think at a minimum the above error text should have been output by SWA to give a clue as to the problem.
And ideally, the process failing in this way should result in SWA terminating with an error. There is no sense waiting for something that will never finish.

To Reproduce

While the below steps show how to reproduce the error by deliberately omitting the libicu dependency, consider that this problem can occur with any possible error that would cause StaticSitesClient to terminate (bug, API error, other runtime dependency issue, out of memory). The real problem is the confusion and lack of useful output, not what might trigger the error.

1. Cause StaticSitesClient to error on launch by removing libicu. For example, on the latest fedora:41 container:

   $ dnf remove libicu   # WARNING: do not run this on a system you care about. on my minimal system, it removes cleanly, but if it wants to remove your entire GNOME desktop consider a different machine.
   

2. ~/.swa/deploy/*/StaticSitesClient should return an error at this point
3. Run swa deploy
4. Observe that the error isn't propagated to swa, and it hangs on Preparing deployment. Please wait...

Expected behavior

I expect the error from StaticSitesClient to be reported to the user.

I don't think SWA should reinterpret and obscure the error, as it might not be possible to catch every single error. For example, in #867 the root cause was the wrong architecture binary being run, and the error behaviour would be highly platform or issue specific.

Desktop (please complete the following information):

I reproduced the issue on:

• Workstation: Fedora Silverblue 41 updated to latest at time of writing
• with a Podman container running the latest fedora:41 container at time of writing, with Node.js v22.11.0 runtime

[boris-ning-usds]

I just ran into the same error trying to deploy docusaurus today, and couldn't figure out what the error Could not find StaticSitesClient local binary meant.

I just tried installing libicu-dev on ubuntu-latest sudo apt-get install -y libicu-dev as part of the workflow, but that didn't seem to work either. Installing libici-dev via sudo apt-get install -y libicu-dev on ubuntu-latest is a legitimate workaround. I had applied to the wrong workflow and didn't see the results come through.

    runs-on: ubuntu-latest
      # Workaround for https://github.com/azure/static-web-apps-cli/issues/914
      - name: Install workaround
        run: |
          sudo apt-get -y install libicu-dev

[jeremyvisser]

I would rather keep discussion in this issue related to the root cause I mentioned above, rather than the tangential error I happened to quote.

I’m tempted to edit my original post to completely obscure the actual underlying error, for fear that the issue will be missed like what happened with #615.