Failed to load staticwebapp.config.json schema on start
StanSymphonia opened this issue · comments
I'm using the latest version 1.1.4
Are you accessing the CLI from the default port :4280 ?
- No, I am using a different port number (
--port) and accessing the CLI from that port - Yes, I am accessing the CLI from port
:4280
Describe the bug
When starting an app with swa start I get WARNING: Failed to load staticwebapp.config.json schema. Continuing without validation!.
Even if it's just a warning and is referring to the schema file (not the config itself) staticwebapp.config.json doesn't work as expected. e.g. none of the routes declared is working.
To Reproduce
Steps to reproduce the behavior:
- Go to any swa app
- Type in command 'swa start'
- See warning in console
- Check in browser any routes declared -> won't work.
Expected behavior
staticwebapp.config.json to work. Routes and any other settings declared to work.
Desktop (please complete the following information):
- OS: Windows
- Version: 11
Additional context
After investigating this issue i have discovered that the URL used to load the config schema is hardcoded: https://github.com/Azure/static-web-apps-cli/blob/affefb24872286a542fe7bbd54340648ec3294d0/src/core/utils/user-config.ts#L168C13-L168C13 .
At this moment, the website https://www.schemastore.org/ which is hosting the schema file, is down (error 503).
Allowing loading the schema file only from a single website has created a single point of failure which we are experiencing right now.
staticwebapp.config.json has a property $schema, but as you can see the value is not used for actually loading the schema.
My suggestion is to allow the user to provide a value for $schema (in order to no longer depend on https://www.schemastore.org/ ).
Thank you.
Edit: there's currently an issue on Schemastore repository: SchemaStore/schemastore#3303
I'm also seeing this warning, but routes are loading okay. I am using a customised config file swa-cli-config.json
My redirect from /login causes an error and the swa auth emulator does not seem to be protecting/allowing routes correctly. Trying to determine if related to above issue or not...
I have this issue also. It fails silently and won't load my settings.
I use the config to set CORS, so my deployment is not accessible at all from my app.
I cannot deploy anymore until I have a solution for this. I'm completely blocked.
Please, do you have a solution ?
I'm also running into this issue. Just had a new deployment, and users are redirected to 404 page if they try to access links directly or refresh the page.
Seeing the same problem. This does also affect the swa deploy command leading to a not working SWA
Temporary solution (what I did):
- Go to
%userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils(for Windows). - Open
user-config.js. - Search for
https://json.schemastore.org/staticwebapp.config.json. - Upload
staticwebapp.config.jsonto blob storage (for example) or use my file:https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json(Will be removed in 24H) - Replace
https://json.schemastore.org/staticwebapp.config.jsonwith your remote path.
Temporary solution (what I did):
- Go to
%userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils(for Windows).- Open
user-config.js.- Search for
https://json.schemastore.org/staticwebapp.config.json.- Upload
staticwebapp.config.jsonto blob storage (for example) or use my file:https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json(Will be removed in 24H)- Replace
https://json.schemastore.org/staticwebapp.config.jsonwith your remote path.
Confirm this fix by @aresofficial for the issue I observed...
I'm also seeing this warning, but routes are loading okay. I am using a customised config file swa-cli-config.json
My redirect from /login causes an error and the swa auth emulator does not seem to be protecting/allowing routes correctly. Trying to determine if related to above issue or not...
I can confirm that issue as well on 1.1.4. Also, the fix posted by @aresofficial is working for me.
That's really strange, how Azure position Static Web Apps as production-ready service, where your app can be totally inaccessible because of downtime on 3rd party service.
Moreover, not a single failure was seen, swa deploy will silently deploy your app and destroy all routes. That's "amazing"
As we are on linux when deploying, sadly the workaround does not work. One approach could be to setup a webserver which serves the schema. One could then point the building/deploying machine for the SWA to this server via a hosts entry 🤔
It seems to be fixed.
Yes and no... someone threw more hardware on the problem so it works for now but the problem persists. One still depends on the availability of https://www.schemastore.org/. Not quite what i would call "fixed" :)
There was some problem in https://json.schemastore.org so that swa-cli got Error 500 Timeout. I have validate that it works well now, so I will close the issue. Feel free to repoen it if the error occurs again.
Really? Is it fixed so that when the schemastore isn't available it at least throws some kind of error and does not deploy a not working swa?..
I think it is not fixed.
I agree with @avalor1 . We should not depend on a third-party service which can become unavailable without notice.
Edit:
My understanding is that the purpose of https://json.schemastore.org/ is to be used by various IDEs and VSCode extensions and SWA-CLI is using it for essential functionalities (build and deploy); even then it just logs a warning if it's unavailable.
At the very least, on deployment it should throw an error when the service is unavailable. This way we'll avoid having broken SWAs in production. (and again wait for the service to become available 🙃)
The issue is not fixed, Static Web Apps CLI is still unstable.
It's only a matter of time before problem recurs (e.g. because of outage on schemastore)
Deployment should at least not silently destroy routes, otherwise Static Web Apps can't be production-ready (as now).
@cjk7989 can you please escalate this issue?
As others mentioned, this is still not fixed.
Hi all, we have published swa-cli@v1.1.5, which will throw an error if staticwebapp.config.json schema is failed to be download. And we plan to design a fallback method to completely fix the issue in the next version. Thanks very much for your feedback and suggestions.
I think validating the schema should be optional, either by not throwing an error or skipping it all together via a flag.
Also the current log message ("Continuing without validation") implies that the validation is optional right now, which is not the case since it breaks the build.
Either way, the domain https://json.schemastore.org/ is currently not listed in the troubleshooting section as domains that should be added to your firewall.
The current error is still "Continuing without validation". That will confuse users since it's aborting execution.
I see this issue in 1.1.6. Emulator does not work without internet. Fails to start.
[swa] ✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
[swa] node ".pnpm/@azure+static-web-apps-cli@1.1.6/node_modules/@azure/static-web-apps-cli/dist/msha/server.js" exited with code 0
Good morning. Can't locally start my Azure static web app because ....
network timeout at: https://json.schemastore.org/staticwebapp.config.json
The schema store is just sending 429 and 503s
I agree that this is a weird network dependency on what should should be "Airplane mode" type local dev work.
I followed @LiamOSullivan steps above but rather than putting in a new blob address I increased the time out
- Go to %userprofile%\AppData\Roaming\npm\node_modules@azure\static-web-apps-cli\dist\core\utils (for Windows).
- Open user-config.js.
- Search for https://json.schemastore.org/staticwebapp.config.json.
- Two line below increase the time out to 10000 milliseconds
- Save and retry
It's happening, right now.... AGAIN!!!!!
Please, reopen and FIX this.
Temporary solution (what I did):
1. Go to `%userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils` (for Windows). 2. Open `user-config.js`. 3. Search for `https://json.schemastore.org/staticwebapp.config.json`. 4. Upload `staticwebapp.config.json` to blob storage (for example) or use my file: `https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json` **(Will be removed in 24H)** 5. Replace `https://json.schemastore.org/staticwebapp.config.json` with your remote path.
Thank you for solution!
I was able to patch @azure/static-web-apps-cli for my deployment pipelines to use custom url instead of https://json.schemastore.org/staticwebapp.config.json.
patches/@azure+static-web-apps-cli+1.1.6.patch
diff --git a/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js b/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
index 00861dd..0f69e81 100644
--- a/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
+++ b/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
@@ -149,7 +149,7 @@ function findLineAndColumnByPosition(content, position) {
return notFound;
}
async function loadSWAConfigSchema() {
- const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json";
+ const schemaUrl = process.env.STATICWEBAPP_CONFIG_SCHEMA_JSON_URL || "https://json.schemastore.org/staticwebapp.config.json";
try {
const res = await (0, node_fetch_1.default)(schemaUrl, { timeout: 10 * 1000 });
if (res.status === 200) {
package.json
{
"scripts": {
"postinstall": "patch-package"
},
"dependencies": {
"@azure/static-web-apps-cli": "1.1.6",
"patch-package": "^8.0.0",
"postinstall-postinstall": "^2.1.0"
}
}.env
STATICWEBAPP_CONFIG_SCHEMA_JSON_URL=https://example.com/staticwebapp.config.schema.json
@cjk7989 this should really be reopened, https://json.schemastore.org being down caused a monorepo with hundreds of devs to block all pull requests. We should be able to provide a local fallback.
@cjk7989 Friday, I was able to bring my SWA up just fine locally for testing during development. Tonight, I ran everything with the exact same configuration and I get this error. Are there really no parameters I could supply to have it not reach out to a spotty third party?
Currently swa fails to start locally because of this error:
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.
Having a way of doing local validation is not the solution. We would still see default pipelines to fail each time someone decides to attack schemas tore.org
I think validation shloud be non-fatal at build time, it will be redone by swa api during publish. An optional parameter to force fatal errors on validation would be nice to have for some scenarios.
Here's a simple fix that skips the validation (as the message says) instead of killing process. Some reordering of rows and missing schema returns config instead of null.
File: node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
async function validateRuntimeConfigAndGetData(filepath) {
const ajv4 = new ajv_draft_04_1.default({
strict: false,
allErrors: true,
});
logger_1.logger.silly(`Reading content from staticwebapp.config.json...`);
const content = (await readFile(filepath)).toString("utf-8");
let config;
try {
logger_1.logger.silly(`Parsing staticwebapp.config.json...`);
config = JSON.parse(content);
}
catch (err) {
printJSONValidationWarnings(filepath, content, err.message);
return null;
}
logger_1.logger.silly(`Loading staticwebapp.config.json schema...`);
const schema = await loadSWAConfigSchema();
if (!schema) {
logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`);
return config;
}
logger_1.logger.silly(`Compiling schema...`);
const validate = ajv4.compile(schema);
logger_1.logger.silly(`Validating staticwebapp.config.json...`);
const isValidSWAConfigFile = validate(config);
if (!isValidSWAConfigFile) {
printSchemaValidationWarnings(filepath, config, validate);
return null;
}
logger_1.logger.silly(`File validated successfully. Continuing with configuration!`);
return config;
}
Thanks for the feedback. It’s an intermittent bug but occurs more common recently. We are going to have a local backup schema as a fallback option if the download fails. The fix will come soon.
Here's a simple fix that skips the validation (as the message says) instead of killing process. Some reordering of rows and missing schema returns config instead of null. File: node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
async function validateRuntimeConfigAndGetData(filepath) { const ajv4 = new ajv_draft_04_1.default({ strict: false, allErrors: true, }); logger_1.logger.silly(`Reading content from staticwebapp.config.json...`); const content = (await readFile(filepath)).toString("utf-8"); let config; try { logger_1.logger.silly(`Parsing staticwebapp.config.json...`); config = JSON.parse(content); } catch (err) { printJSONValidationWarnings(filepath, content, err.message); return null; } logger_1.logger.silly(`Loading staticwebapp.config.json schema...`); const schema = await loadSWAConfigSchema(); if (!schema) { logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`); return config; } logger_1.logger.silly(`Compiling schema...`); const validate = ajv4.compile(schema); logger_1.logger.silly(`Validating staticwebapp.config.json...`); const isValidSWAConfigFile = validate(config); if (!isValidSWAConfigFile) { printSchemaValidationWarnings(filepath, config, validate); return null; } logger_1.logger.silly(`File validated successfully. Continuing with configuration!`); return config; }
Saved my teams morning productivity, thank you!
Temporary solution (what I did):
- Go to
%userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils(for Windows).- Open
user-config.js.- Search for
https://json.schemastore.org/staticwebapp.config.json.- Upload
staticwebapp.config.jsonto blob storage (for example) or use my file:https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json(Will be removed in 24H)- Replace
https://json.schemastore.org/staticwebapp.config.jsonwith your remote path.
Thank you. I have found another way to solve it. And it works without hosting the staticwebapp.config.json file
So instead of simply replacing the URL, I increased the timeout to 5 minutes instead of just 10 seconds, as the only issue was I was able to load the file in browser but it would take more than 10 seconds.
Here's how you can do it:
- Go to
user-config.js - Find
const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json";and below there's a line with timeout set to10 * 1000 - Change the
10to whatever number you think works - Reload your terminal (it wasn't working without it)
PS. Finding user-config was tricky because it was installed globally and since I am using nvm mine was located at ~/.nvm/versions/node/v18.18.0/lib/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
I disabled validation until this gets resolved:
/*
const schema = await loadSWAConfigSchema();
if (!schema) {
logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);
return null;
}
logger_1.logger.silly(`Compiling schema...`);
const validate = ajv4.compile(schema);
*/
const validate = () => true;
A quick way to use the CLI until this is resolved is to remove the "true" parameter to the logger.error method, as this causes the script to exit:
static-web-apps-cli/src/core/utils/user-config.ts
This:
logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`);
instead of this:
logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);
Credit to @cristianbretti
I probably understood this problem.
In loadSWAConfigSchema(), there is a process to load data from the following SchemaURL, right?
const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json";Currently, it seems that the data delivery for this URL is very slow.
This is causing a timeout.
Additional information: This URL cannot be accessed.
In conclusion, it seems that this issue occurs at least during a period when the distribution of the above SchemaURL is unstable.
A quick way to use the CLI until this is resolved is to remove the "true" parameter to the logger.error method, as this causes the script to exit:
static-web-apps-cli/src/core/utils/user-config.ts
This:
logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`);instead of this:logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);Credit to @cristianbretti
Removing the "true" from logger_1.logger.error to skip validation will cause the routing to not work. I recommend the two temporary solutions mentioned by @zainzafar90, to save the schema into Azure blob storage, or set the timeout to a larger value.
I think the following measures are necessary.
Add processing that allows individuals to specify Schema for development by dividing the URL that distributes Schema into multiple parts or as an option.
Please have an image like the following.
swa start --schema "https://[alterbaseurl]/staticwebapp.config.json"Can we skip accessing the network for the commands that does not require it? I am often find myself working on the plane with unstable internet connection. I don’t understand why do I need to download anything from the Internet if I just want to test the app. For deployment we may have additional arguments.
Solved with workaround!!
After few hrs of struggle and understand I finally got it work by storing schema to different host and pointing updating the same in user-config.js.
Thanks @cjk7989
Note: For mac os, path for file is: /usr/local/lib/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js.
depends on node installation directory.
change the schemaUrl in the file to your hosted schema path.
Those who need the content of the schema to host, I have a copy of it at: https://anuraggandhi.com/schema-swa.config.json.
(please don't use it directly from this host. It will be removed shortly.)
I think the following measures are necessary. Add processing that allows individuals to specify Schema for development by dividing the URL that distributes Schema into multiple parts or as an option.
Please have an image like the following.
swa start --schema "https://[alterbaseurl]/staticwebapp.config.json"
While I acknowledge that this issue arises due to current circumstances, it undermines the essence of validation.
Allowing users to easily upload their own flawed schemas poses a risk, particularly if they become outdated and desynchronized with the latest schema over time.
If validation doesn't happen against latest schema, this could subsequently lead to additional complications in production environments.
All builds fall down because of this issue
All builds fall down because of this issue
I understand, I also have the same set of frustration as my deployment delayed by many hrs due to this.
Hope MS will fix it intelligently and will not rely on 3rd party sites for their production ready tools.
Better solution, i think: MS should host the schemas themselves to a relied host and use them for their tools. They should take care of updating the schema when needed.
I think the following measures are necessary. Add processing that allows individuals to specify Schema for development by dividing the URL that distributes Schema into multiple parts or as an option.
Please have an image like the following.swa start --schema "https://[alterbaseurl]/staticwebapp.config.json"While I acknowledge that this issue arises due to current circumstances, it undermines the essence of validation. Allowing users to easily upload their own flawed schemas poses a risk, particularly if they become outdated and desynchronized with the latest schema over time. If validation doesn't happen against latest schema, this could subsequently lead to additional complications in production environments.
Yes, I do not intend to use this in a production environment, but rather to use it for development to temporarily deal with issues that are currently occurring.
The solution shouldn't be reliant upon any specific host, MS controlled or otherwise. Its a dependency that can cause the current pain points many of us are receiving.
Why not ship a fallback schema with the tool, kept up to date with each update.
The solution shouldn't be reliant upon any specific host, MS controlled or otherwise. Its a dependency that can cause the current pain points many of us are receiving.
Why not ship a fallback schema with the tool, kept up to date with each update.
I think this is the proposal that should be given the most preferential treatment.
Better yet, don't perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn't be any hard-coded dependency on a remote server being available.
Better yet, don't perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn't be any hard-coded dependency on a remote server being available.
I wouldn't use the CLI for production deployments anyway, it's mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path's etc. and the GitHub action doesn't rely on the CLI.
You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.
Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.
Better yet, don't perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn't be any hard-coded dependency on a remote server being available.
I wouldn't use the CLI for production deployments anyway, it's mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path's etc. and the GitHub action doesn't rely on the CLI.
You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.
Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.
All of the other options rely on this under the hood. So doing anything that doesn't rely on this isn't an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I'd just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it's the only way to get resources to Azure Static Sites.
Better yet, don't perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn't be any hard-coded dependency on a remote server being available.
I wouldn't use the CLI for production deployments anyway, it's mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path's etc. and the GitHub action doesn't rely on the CLI.
You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.
Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.All of the other options rely on this under the hood. So doing anything that doesn't rely on this isn't an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I'd just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it's the only way to get resources to Azure Static Sites.
That is not correct @nathanblair, the GitHub action doesn't rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems.
There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.
I hope that we can settle on the fact that "local development" does not require fetching anything from the internet. :)
One other interesting observation that I would like to point out: I didn't know that there is a validation until I went offline. I am not clear on why this is required and can this be optional? (activated using --strict or --validate arg)
In any case making start command not rely on the internet - that is my main request.
Thank you!
+1 on not relying on the internet by default
A warning about impossible validation is enough
Hi all, the fix has been merged in PR #808. In summary, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.
Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:
- git clone https://github.com/Azure/static-web-apps-cli.git
- cd into the folder "static-web-apps-cli"
- run "npm install", then "npm run build"
- run "npm link ./", which allows you to use this version of swa-cli globally.
- * if you want to update the version of swa-cli, just delete this local folder "static-web-apps-cli" and run "npm install -g @azure/static-web-apps-cli" to reinstall the official version.
Thanks a lot for checking if this update works for you.
@cjk7989 Thank you so much for this - I think I speak for many that this is a great fix and will help loads. Was able to check PR and LGTM, not able to test it out right this second though sorry. Is there an estimated release window for the next version?
Better yet, don't perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn't be any hard-coded dependency on a remote server being available.
I wouldn't use the CLI for production deployments anyway, it's mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path's etc. and the GitHub action doesn't rely on the CLI.
You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.
Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.
All of the other options rely on this under the hood. So doing anything that doesn't rely on this isn't an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I'd just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it's the only way to get resources to Azure Static Sites.
That is not correct @nathanblair, the GitHub action doesn't rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (
mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems.There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.
Not everyone has ability to use the GitHub Action for their deployment and should not be required to do so. Again, the underlying tool should be open sourced to begin with
...
That is not correct @nathanblair, the GitHub action doesn't rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (
mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems.
There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.Not everyone has ability to use the GitHub Action for their deployment and should not be required to do so. Again, the underlying tool should be open sourced to begin with
That is what the container image mcr.microsoft.com/appsvc/staticappsclient:stable is for ;)
This is not the right place to request a certain tool to be open sourced. If you want to request other tools for the deployment
or something to be open sourced, you could open a separate issue for that.
The important part is that the SWA CLI should not be part of production release tooling and that the tools for that are the container image and the GitHub action. There is currently no dependency on the CLI for production deployments.
Hi all, the fix has been merged in PR #808. In sumarry, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.
Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:
- git clone https://github.com/Azure/static-web-apps-cli.git
- cd into the folder "static-web-apps-cli"
- run "npm install", then "npm run build"
- run "npm link ./", which allows you to use this version of swa-cli globally.
- if you want to update the version of swa-cli, just delete this local folder "static-web-apps-cli" and run "npm install -g @azure/static-web-apps-cli" to reinstall the official version.
Thanks a lot for checking if this update works for you.
Thanks a lot for the quick fix @cjk7989 🚀 I tested the PR branch locally and the original problem is fixed.
Hello,
I still have problem to deploy my application through Azure DevOps.
Here is the output :
Deploying to environment: production
network timeout at: https://json.schemastore.org/staticwebapp.config.json
✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
##[debug]Exit code 1 received from tool 'C:\Program Files\Git\bin\bash.exe'
##[debug]STDIO streams have closed for tool 'C:\Program Files\Git\bin\bash.exe'
##[debug]task result: Failed
##[error]Script failed with exit code: 1
##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1
##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1
Even if it says that it would "Continuing without validation!", the deployment still fail.
It seems that https://json.schemastore.org/staticwebapp.config.json still have a timeout.
How can I manage to avoid that validation ?
Do I need to deploy throught Azure CLI, would it help ?
Maybe I could use a script in my deploy.yml template, but not sure how to do it...
Thanks for your help !
@PothieuG I don't think the npm package has been published yet: https://www.npmjs.com/package/@azure/static-web-apps-cli?activeTab=versions.
I imagine it'll get published later once @cjk7989 see's that it's been tested by some individuals here, see the request here. I'm also guessing there are timezone limitations too
1.1.7-alpha works good, problem seems to be fixed.
If someone is using docker in CI, i did the following: created a copy of https://json.schemastore.org/staticwebapp.config.json into my github repository and in my CI file, just after "npm install -g @azure/static-web-apps-cli", i added:
"- sed -i 's,https://json.schemastore.org/staticwebapp.config.json,{{MY_FILE_ON_MY_GITHUB_REPO}},g' /usr/local/lib/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js"
1.1.7-alpha works good, problem seems to be fixed.
Can't find any reference to 1.1.7-alpha anywhere, can you help?
Hello,
I still have problem to deploy my application through Azure DevOps. Here is the output :
Deploying to environment: production network timeout at: https://json.schemastore.org/staticwebapp.config.json ✖ Failed to load staticwebapp.config.json schema. Continuing without validation! ##[debug]Exit code 1 received from tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]STDIO streams have closed for tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]task result: Failed ##[error]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1Even if it says that it would "Continuing without validation!", the deployment still fail. It seems that https://json.schemastore.org/staticwebapp.config.json still have a timeout.
How can I manage to avoid that validation ? Do I need to deploy throught Azure CLI, would it help ? Maybe I could use a script in my deploy.yml template, but not sure how to do it...
Thanks for your help !
For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines).
The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.
I followed these instructions from cjk7989. This installs 1.17-alpha ,which solved the problem for me.
Hi all, the fix has been merged in PR #808. In sumarry, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.
Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:
- git clone https://github.com/Azure/static-web-apps-cli.git
- cd into the folder "static-web-apps-cli"
- run "npm install", then "npm run build"
- run "npm link ./", which allows you to use this version of swa-cli globally.
- if you want to update the version of swa-cli, just delete this local folder "static-web-apps-cli" and run "npm install -g @azure/static-web-apps-cli" to reinstall the official version.
Thanks a lot for checking if this update works for you.
Downgrade temporary to 1.1.4. A warning is visible but not error
Hello,
I still have problem to deploy my application through Azure DevOps. Here is the output :Deploying to environment: production network timeout at: https://json.schemastore.org/staticwebapp.config.json ✖ Failed to load staticwebapp.config.json schema. Continuing without validation! ##[debug]Exit code 1 received from tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]STDIO streams have closed for tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]task result: Failed ##[error]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1Even if it says that it would "Continuing without validation!", the deployment still fail. It seems that json.schemastore.org/staticwebapp.config.json still have a timeout.
How can I manage to avoid that validation ? Do I need to deploy throught Azure CLI, would it help ? Maybe I could use a script in my deploy.yml template, but not sure how to do it...
Thanks for your help !For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines). The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.
Requiring the use of actions/tasks for deploying static assets to a web server is not a good enough solution. That's unrelated to the problem with the CLI but then so is recommending alternatives that "don't use it" (PS, looked at the container image manifest, it does indeed use the same tooling and scripting that the CLI uses).
Hi all, the fix has been merged in PR #808. In summary, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.
Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:
- git clone https://github.com/Azure/static-web-apps-cli.git
- cd into the folder "static-web-apps-cli"
- run "npm install", then "npm run build"
- run "npm link ./", which allows you to use this version of swa-cli globally.
- if you want to update the version of swa-cli, just delete this local folder "static-web-apps-cli" and run "npm install -g @azure/static-web-apps-cli" to reinstall the official version.
Thanks a lot for checking if this update works for you.
Worked for me publishing from within VS2022.
Here's a solution that worked for us until a release is published. We are using the SWA CLI in GitHub Actions, installed locally as a dev dependency of the project. So we installed the CLI using the latest commit hash to get the unreleased fix:
"@azure/static-web-apps-cli": "github:Azure/static-web-apps-cli#34864d0a78e971ebdf2b8721fe0a7bfccc0000c3",
In our case, the deployment was going through instead of failing and it resulted in the SWA configuration not being applied, which meant our 404 page and redirects were not working anymore in production.
Hello,
I still have problem to deploy my application through Azure DevOps. Here is the output :Deploying to environment: production network timeout at: https://json.schemastore.org/staticwebapp.config.json ✖ Failed to load staticwebapp.config.json schema. Continuing without validation! ##[debug]Exit code 1 received from tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]STDIO streams have closed for tool 'C:\Program Files\Git\bin\bash.exe' ##[debug]task result: Failed ##[error]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1 ##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1Even if it says that it would "Continuing without validation!", the deployment still fail. It seems that https://json.schemastore.org/staticwebapp.config.json still have a timeout.
How can I manage to avoid that validation ? Do I need to deploy throught Azure CLI, would it help ? Maybe I could use a script in my deploy.yml template, but not sure how to do it...
Thanks for your help !For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines). The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.
But the “AzureStaticWebApp” task does not work, when bash is not installed on the agent (ex. on self-hosted windows agents).
microsoft/azure-pipelines-tasks#19447
Even when using Azure DevOps CI/CD pipeline it is not always possible to use the task.
...
For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines). The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.
Requiring the use of actions/tasks for deploying static assets to a web server is not a good enough solution. That's unrelated to the problem with the CLI but then so is recommending alternatives that "don't use it" (PS, looked at the container image manifest, it does indeed use the same tooling and scripting that the CLI uses).
Just to clarify some things in case anyone stumbles upon this issue. Neither the container image nor the GitHub/GitLab/etc. task has any dependency on the CLI and this issue is a pure CLI issue (fixed in 1.1.7).
The only part of the CLI that uses the same tools as the container image is the deploy command, which still works without any problems as the validation in the deployment tooling has no dependency on the external schema and has it's own schema validation written in C#.
Currently the CLI lacks support for some parameters and variables for deployment, which is why the container image and the task are the recommended options. As the container image is available in the public MS registry, there is no requirement to use actions/tasks for deployment and like with many other projects, the container image can just be used locally if no CI system is available.
I totally support improving the CLI deploy command to a level where it has the same deployment capabilities as the image/task, because not everyone has the same knowledge of containers and it would thereby reduce friction.
If you want to dive deeper or get a better understanding for the SWA-Client executable feel free to follow up offline @nathanblair.
Close it as swa-cli@v1.1.7 has been released and fixed this issue, thanks very much for all your feedback and suggestions.