Dependency on json.schemastore.org breaks CLI about static-web-apps-cli HOT 21 CLOSED

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.

from static-web-apps-cli.

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: #754 (comment). The official release will come soon.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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

from static-web-apps-cli.

Another workaround is to use version 1.1.4.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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

   static-web-apps-cli/src/core/utils/user-config.ts

   Line 108 in f9f9b7e

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

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.

from static-web-apps-cli.

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

from static-web-apps-cli.

@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.

static-web-apps-cli/src/core/utils/user-config.ts

Line 108 in f9f9b7e

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

from static-web-apps-cli.

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

from static-web-apps-cli.

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

from static-web-apps-cli.

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.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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

from static-web-apps-cli.

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)

from static-web-apps-cli.

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.

from static-web-apps-cli.

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.

from static-web-apps-cli.

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.

from static-web-apps-cli.

Same problem

from static-web-apps-cli.