Dapr init can fail due to rate-limit on Github Releases API even when --runtime-version is specified

rynowak commented 7 months ago

Expected Behavior

Dapr init succeeds 😄

In this case we're running:

wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash -s 1.11.0
dapr init -k --wait --timeout 600 --runtime-version 1.11.0

We're trying to avoid autodetection of the Dapr version because we've seen this fail routinely due to rate-limiting by the Github Releases API.

Actual Behavior

Your system is linux_amd64
Installing Dapr CLI...

Installing v1.11.0 Dapr CLI...
Downloading https://github.com/dapr/cli/releases/download/v1.11.0/dapr_linux_amd64.tar.gz ...
dapr installed into /usr/local/bin successfully.
CLI version: 1.11.0 
Runtime version: n/a

To get started with Dapr, please visit https://docs.dapr.io/getting-started/
⌛  Making the jump to hyperspace...
ℹ️  Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced

ℹ️  Container images will be pulled from Docker Hub
✅  Deploying the Dapr control plane with 1.11.0 version to your cluster...
❌  cannot get the latest release version: https://api.github.com/repos/dapr/dashboard/releases - 403 Forbidden
❌  Deploying the Dapr dashboard with latest version to your cluster...

Steps to Reproduce the Problem

Run the following from a high-traffic source, for example inside a Github Actions pipeline. The problem is due to rate-limiting, so the context where this command is being run matters. We're seeing failures in maybe 1/20 cases.

wget -q https://raw.githubusercontent.com/dapr/cli/master/install/install.sh -O - | /bin/bash -s 1.11.0
dapr init -k --wait --timeout 600 --runtime-version 1.11.0

Release Note

RELEASE NOTE: FIX dapr init with a specific version no longer has a dependency on the Github API, and is no longer susceptible to Github API Rate Limits.

rynowak commented 7 months ago

Upon looking through the code, it looks like we may be hitting this due to not specifying the --dashboard-version.

Since we're not specifying the dashboard version I think it's doing a lookup rather than assuming we want to match the version of the runtime.

Does this make sense? I would have assumed it's better for the versions to match unless the user asked for something else. In the interim, I'll try specifying the --dashboard-version as well.

mukundansundar commented 7 months ago

Upon looking through the code, it looks like we may be hitting this due to not specifying the --dashboard-version.

Since we're not specifying the dashboard version I think it's doing a lookup rather than assuming we want to match the version of the runtime.

Does this make sense? I would have assumed it's better for the versions to match unless the user asked for something else. In the interim, I'll try specifying the --dashboard-version as well.

Dashboard version is completely independent of the runtime version, so if not specified, it will be looked up from GitHub.

rynowak commented 7 months ago

In the interim, I'll try specifying the --dashboard-version as well.

By the way, I can confirm that specifying --dashboard-version solved the issue for me.

dapr-bot commented 6 months ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

dapr-bot commented 6 months ago

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

dapr / cli