Azure / static-web-apps-cli

Azure Static Web Apps CLI ✨
https://aka.ms/swa/cli-local-development
MIT License
596 stars 117 forks source link

Dependency on json.schemastore.org breaks CLI #802

Closed itpropro closed 6 months ago

itpropro commented 7 months ago

The SWA CLI currently fails and stops after a few seconds, because either the latency of https://json.schemastore.org/staticwebapp.config.json is too high or the service is not available. There should be no dependency on an online resource to be available for local development. From the logs it seems like it should continue to work without validation, but it currently doesn't.

Logs:

[swa] network timeout at: https://json.schemastore.org/staticwebapp.config.json
[swa] ✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
[swa] node "C:\Users\USER\AppData\Local\pnpm\global\5\.pnpm\@azure+static-web-apps-cli@1.1.6\node_modules\@azure\static-web-apps-cli\dist\msha\server.js" exited with code 0
--> Sending SIGTERM to other processes..
[dataApi] cd "C:\repos\APP\data-api" && "C:\Users\USER\.swa\dataApiBuilder\0.9.7\Microsoft.DataApiBuilder.exe" start -c staticwebapp.database.config.json --no-https-redirect exited with code 1
--> Sending SIGTERM to other processes..
[run] cd "C:\repos\APP\app" && pnpm dev exited with code 1
✖ SWA emulator stopped because the --run command exited with code 1.

My suggestion would be to increase the timeout for the request and to fix the bug that stops the CLI from working without validation.

cristianbretti commented 7 months ago

Heavy plus one! We use this CLI deploy our production sites, so this is really blocking us from release

It is this line that makes this fail. It should not send true as the second argument as true is used to signal logger.error to exit the program.

https://github.com/Azure/static-web-apps-cli/blob/f9f9b7e92f5fb03cf9b75626377f951a5f85cd5d/src/core/utils/user-config.ts#L108

nerblock commented 7 months ago

Same problem here:

network timeout at: https://json.schemastore.org/staticwebapp.config.json
[swa] ✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
(...)
✖ SWA emulator stopped because API server exited with code 1.
OlliejED commented 7 months ago

Also having this problem, since the 1st of March:

[swa] network timeout at: https://json.schemastore.org/staticwebapp.config.json
[swa] ✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
[swa] node "<local path>\node_modules\@azure\static-web-apps-cli\dist\msha\server.js" exited with code 0    
--> Sending SIGTERM to other processes..
[api] cd "<local path>" && "func" start --cors "*" --port <host port>  exited with code 1
✖ SWA emulator stopped because API server exited with code 1.
cjk7989 commented 7 months ago

Thanks for all of your feedback. We are going to have a local backup schema as a fallback option if the download fails. I have reopened the issue #754, and the fix will come soon.

OlliejED commented 7 months ago

@cjk7989 would it be possible to either remove the "true" parameter, as @cristianbretti mentioned, from the error log or adjust the log to be more accurate as to what happens next? Currently, the log implies the CLI will run as normal when in fact it closes due to the included parameter:

It is this line that makes this fail. It should not send true as the second argument as true is used to signal logger.error to exit.

https://github.com/Azure/static-web-apps-cli/blob/f9f9b7e92f5fb03cf9b75626377f951a5f85cd5d/src/core/utils/user-config.ts#L108

rhuanbarreto commented 7 months ago

Very critical issue for us here! Deployments are stopped because the schema cannot be loaded.

jancimajek commented 7 months ago

Same here; this is blocking our deployment pipeline. I appreciate the quick response from @cjk7989 and will be (patiently) waiting for a quick fix 🤞

cristianbretti commented 7 months ago

Don't know if this helps anyone, but I did the following this morning to unblock all of our deployment pipelines.

  1. Download this repo
  2. Change this line to pass false, as the second argument to logger.error https://github.com/Azure/static-web-apps-cli/blob/f9f9b7e92f5fb03cf9b75626377f951a5f85cd5d/src/core/utils/user-config.ts#L108
  3. Build and deploy to my own private registry
    1. Change the name in package.json to @myprivateorg/static-web-apps-cli-hotfix
    2. npm run build
    3. npm pack
    4. npm publish
  4. Change my deploy pipelines to use npx @myprivateorg/static-web-apps-cli-hotfix ... instead of npx @azure/static-web-apps-cli

This worked for us, but some maintainer said here that this might not work 🤷 I guess do this at your own risk or whatever.

dagskage commented 7 months ago

What is the current status for resolving this issue @cjk7989 ?

lustef commented 7 months ago

Hey! What about your start scripts? I had a similar issue and realized that I had a bit incorrect script. It came up after upgrading the version from 1.1.4 to 1.1.6. Following the documentation documentation I set the config location under the -w option. After upgrading, it stopped working. Same story when running in docker.

EDIT: (I changed the option name to --swa-config-location and it got back to work.) NOPE, doesn't work.

itpropro commented 7 months ago

Hey! What about your start scripts? I had a similar issue and realized that I had a bit incorrect script. It came up after upgrading the version from 1.1.4 to 1.1.6. Following the documentation documentation I set the config location under the -w option. After upgrading, it stopped working. Same story when running in docker. I changed the option name to --swa-config-location and it got back to work.

This issue here is only related to a dependency to an external resource during schema validation and appears in 1.1.6 when the schema is successfully loaded.

itpropro commented 7 months ago

Just in case anyone needs a quick workaround without cloning the project, you could just locate your cli package and change one line to make it work.

  1. Locate your @azure/static-web-apps-cli package, for me it's the global pnpm store at C:\Users\USERNAME\AppData\Local\pnpm\global\5\node_modules\.
  2. Navigate to @azure\static-web-apps-cli\dist\core\utils and open user-config.js
  3. Replace true with false as parameter in following line (101 for me) and save

Old

logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);

New

logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, false);

This will not load auth middleware and other things and only works until you update your static-web-apps-cli package, which won't be that often, as it should not be installed per project, but as a global pnpm/bun/yarn/npm dependency.

cridasilva commented 7 months ago

Another workaround is to use version 1.1.4.

k-benedetti commented 7 months ago

Another fix is to just make your own file and host it. Point the user-config.js file to your own configuration. We set that up Friday when schemastore.org went down and so today had a copy to point to. Schemastore.org is going up and down all day and taking a long time to resolve when it is up.

Here is a copy of the file someone posted that I used on Friday: https://[simkuns.dev/staticwebapp.config.schema.json](https://simkuns.dev/staticwebapp.config.schema.json)

aemaem commented 7 months ago

Anyone using Github Actions could use https://github.com/Azure/static-web-apps-deploy directly instead of the SWA CLI (as mentioned in #754).

jancimajek commented 7 months ago

Another workaround is to use version 1.1.4.

Pinning the version to v1.1.4 while waiting on the fix seems to have fixed the issue for us (it still fails to load the schema, but does not fail the whole deployment because of it)

itpropro commented 7 months ago

Another workaround is to use version 1.1.4.

Pinning the version to v1.1.4 while waiting on the fix seems to have fixed the issue for us (it still fails to load the schema, but does not fail the whole deployment because of it)

I would not use the CLI for a deployment in a pipeline etc. it’s mainly made for local development. You can use the container image or the GitHub action for producrion deployments.

jancimajek commented 7 months ago

Pinning the version to v1.1.4 while waiting on the fix seems to have fixed the issue for us (it still fails to load the schema, but does not fail the whole deployment because of it)

I would not use the CLI for a deployment in a pipeline etc. it’s mainly made for local development. You can use the container image or the GitHub action for producrion deployments.

While I generally agree with you, there are often external technical/security/regulatory/auditing requirements that prevent teams & companies from deploying straight from GHA. I don't want to derail this thread by going into more detail, but there are genuine reasons why teams rely on the CLI app for deployments.

cjk7989 commented 7 months ago

Another workaround is to use version 1.1.4.

Pinning the version to v1.1.4 while waiting on the fix seems to have fixed the issue for us (it still fails to load the schema, but does not fail the whole deployment because of it)

Hi @jancimajek, in v1.1.4 SWA-CLI skipped validation and continued deploying if timeout. However, it will make routing to not work. So I recommend not to skip validation, but use the 1.1.7-alpha version with my fix instead: https://github.com/Azure/static-web-apps-cli/issues/754#issuecomment-1977411452. The official release will come soon.

itpropro commented 6 months ago

Pinning the version to v1.1.4 while waiting on the fix seems to have fixed the issue for us (it still fails to load the schema, but does not fail the whole deployment because of it)

I would not use the CLI for a deployment in a pipeline etc. it’s mainly made for local development. You can use the container image or the GitHub action for producrion deployments.

While I generally agree with you, there are often external technical/security/regulatory/auditing requirements that prevent teams & companies from deploying straight from GHA. I don't want to derail this thread by going into more detail, but there are genuine reasons why teams rely on the CLI app for deployments.

I would use the container image then, as the SWA CLI has afaik no guarantees to work outside of the dev/local testing and validation use case. The risk for a production deployment would be much too high for my taste to rely on development tools for production deployments. But if you cannot run containers locally or in your self-hosted CI, there is probably no way to avoid the CLI.

JohnMarsing commented 6 months ago

Same problem