Open derkoe opened 1 year ago
StaticSiteClient is not the only binary used the SWA CLI, there's also the Functions Core Tools. The problem is that there are many possible environments (win32, win64, macOS x64, macOS ARM, linux...) and the same amount of binaries (for each of StaticSiteClient and Functions Core Tools). These tools also have their own release cycle, independent of the SWA CLI, so it's not really possible to bundle them within the Node package. Because the binaries are also quite large, it's downloaded on-demand the first time it's needed to avoid bloating the install and making it too long.
It's a bit buried in the docs, but you can use the env vars SWA_CLI_DEPLOY_BINARY_VERSION
to force the version of the downloaded StaticSiteClient.
It's a bit buried in the docs, but you can use the env vars SWA_CLI_DEPLOY_BINARY_VERSION to force the version of the downloaded StaticSiteClient.
How many versions are made available, and for how long can I reliably access older versions?
To illustrate my concern, the description of #615 includes the following snippet:
Fetching release metadata for version: stable. Please wait...
- version: stable
- buildId: 1.0.020981
- publishDate: 2022-09-29T17:37:34.4094014Z
- files:
- linux-x64:
- url: https://swalocaldeploy.azureedge.net/downloads/1.0.020981/linux/StaticSitesClient
- sha: e55db21d0720a12098804559152303e66846bdd94c13a30b30be29a0fc9ae366
- win-x64:
- url: https://swalocaldeploy.azureedge.net/downloads/1.0.020981/windows/StaticSitesClient.exe
- sha: 4e4eb72aef26641e236c24929c822500e956bda099ca78054112cadf20261107
- osx-x64:
- url: https://swalocaldeploy.azureedge.net/downloads/1.0.020981/macOS/StaticSitesClient
- sha: e0f2ae7ec297510a1b3b9332c0dc0dd962a51adb8ea13cd4f3746d79fc24a7e9
If you try accessing these paths now in a browser, they no longer host the content.
If I had pin a pipeline to version 1.0.020981
with SWA_CLI_DEPLOY_BINARY_VERSION
, the StaticSitesClient cannot be sourced. Because the binary isn't hosted indefinitely (or managed by a package manager that does), then the value of this environment variable is significantly diminished.
Using the latest SWA client pinned to an older StaticSitesClient to perform a deployment
$ SWA_CLI_DEPLOY_BINARY_VERSION='1.0.020981' swa deploy
Welcome to Azure Static Web Apps CLI (1.1.1)
Multiple configurations found in "swa-cli.config.json", but none was specified.
Specify which configuration to use with "swa <command> --config-name <configName>"
Using configuration "all" from file:
/example/swa-cli.config.json
# { ... trimmed for brevity }
Content parsed successfully
Found configuration file:
/example/staticwebapp.config.json
Deploying project to Azure Static Web Apps...
Could not find StaticSitesClient binary: /Users/rossmurray/.swa/deploy/1.0.021731/StaticSitesClient
Fetching release metadata for version: 1.0.020981. Please wait...
undefined
✖
✖ Deployment Failed :(
✖ Deployment Failure Reason: Could not load StaticSitesClient metadata from remote. Please check your internet connection.
✖ For further information, please visit the Azure Static Web Apps documentation at https://docs.microsoft.com/azure/static-web-apps/
✖ If you believe this behavior is unexpected, please raise a GitHub issue at:
https://github.com/Azure/static-web-apps-cli/issues/new/choose
Wow, now version StaticSitesClient@1.0.024941 is throwing an unknown exception and we are unable to deploy our site. It's also impossible to run an older version, even just the previous one that's a week old, as the old ones seem to have been unpublished. It's absolutely a must to be able to do reproducible deploys. You need to take a hard look at this setup, meanwhile I need to find a workaround.
this is what @derkoe warned you about early this year @cjk7989 https://github.com/Azure/static-web-apps-cli/issues/776#issue-1981710689
A year later, this is still a problem - The executable is only 65.9MB in size, but the download speeds are restricted to about 4-5KB/s and it takes forever to download. I get that it has a separate release cycle and it's not bundled with the swa-cli, but at least don't restrict the download speeds.
To add to this, it looks like it outputs an error to stderr
when it does the download: - Downloading https://swalocaldeploy.azureedge.net/downloads/1.0.026792/linux/StaticSitesClient@1.0.026792
.
This causes a build pipeline to fail if it has "fail whenever something is output to stderr" enabled. stderr
should be for errors. "Hey, I don't have this thing, so I'm just downloading it" shouldn't be an error - unless it actually fails to download.
So, can we change that to output to stdout instead? Or call an explicit "swa download the thing that you need" so it's not even a warning because I explicitly tell it that it's A-OK to do so, and probably also create a Docker container that just has it in it?
Is your feature request related to a problem? Please describe.
swa-cli currently downloads a binary called StaticSitesClient from the internet before it uses it to deploy to Azure SWA. This leads to different issues: #557 #594 #615
It is not a good idea to change the behavior of software with the same version.
It is also not a good practice to download and run random code on running an NPM program (it is OK when installing the program).
Describe the solution you'd like
Package the StaticSitesClient with the swa-cli.
Describe alternatives you've considered
You could also pin the version of StaticSitesClient in the swa-cli and download the binary on "npm install". This would at least solve the issue with the change of behavior.