setup-kubectl: Bug: kubectl for amd64 was not found
What happened?
I’m running the following step on my github workflow and got an error telling that the version ‘1.28.2’ for ‘amd64’ was not found.
- name: install kubectl
uses: azure/setup-kubectl@v3
i’ve tried to downgrade the version adding the following, but got the same error:
with:
version: '1.28.2'`
The error is strange because reaching the download link locally on my machine works correctly.
Version
- I am using the latest version
Runner
ubuntu-latest
Relevant log output
##[debug]Evaluating condition for step: 'install kubectl'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: install kubectl
##[debug]Loading inputs
##[debug]Loading env
Run azure/setup-kubectl@v3
##[debug]Downloading https://storage.googleapis.com/kubernetes-release/release/stable.txt
##[debug]Destination /home/runner/work/_temp/8ed25fc3-ddb3-4b8b-847a-244571e4a0e9
##[debug]download complete
##[debug]isExplicit: 1.28.3
##[debug]explicit? true
##[debug]checking cache: /opt/hostedtoolcache/kubectl/1.28.3/x64
##[debug]not found
##[debug]Downloading https://dl.k8s.io/release/v1.28.3/bin/linux/amd64/kubectl
##[debug]Destination /home/runner/work/_temp/50d81c8f-95cc-4889-8d7a-ab8d1a2da771
##[debug]Failed to download from "https://dl.k8s.io/release/v1.28.3/bin/linux/amd64/kubectl". Code(404) Message(Not Found)
Error: Error: Kubectl 'v1.28.3' for 'amd64' arch not found.
##[debug]Node Action run completed with exit code 1
##[debug]Finishing: install kubectl
About this issue
- Original URL
- State: open
- Created 8 months ago
- Reactions: 7
- Comments: 21
Commits related to this issue
- fix(ci): latest azure/setup-kubectl action not working Ref https://github.com/Azure/setup-kubectl/issues/88 — committed to squakez/camel-k by squakez 8 months ago
- fix(ci): latest azure/setup-kubectl action not working Ref https://github.com/Azure/setup-kubectl/issues/88 — committed to apache/camel-k by squakez 8 months ago
- fix(ci): latest azure/setup-kubectl action not working Ref https://github.com/Azure/setup-kubectl/issues/88 — committed to realMartinez/camel-k by squakez 8 months ago
I have a workflow that does not specify a version. It has been working fine for months. Now it fails with the error message shown in the original post here.
This isn’t helping. We’ve tried 1.28.3 which is https://storage.googleapis.com/kubernetes-release/release/stable.txt
Today We’ve tried running 1.28.2 and 1.27.6 of kubectl with the same errors.
I am not in the same organization as him, additionally the issue is sporadic which suggests configuration drift on the runners.
use with: version: “v1.28.2”
works consistently, like they said use a “v” doh!
FWIW: I was able to get it to work by adding a v to my version, like so ‘vX.XX.XX’ in my workflow:
It failed here:
And was successful here:
Please check all (including closed) issues before you post.
https://github.com/Azure/setup-kubectl/issues/87
How is my reply not helping.
We have pinned the version to
v1.28.3
, but it still doesn’t work for us:Full step screenshot
Looking at the final lines:
I click on the URL and succeed in downloading the binary. Using
curl -Li
, I see that I getHTTP/2 302
and thenHTTP/2 200
. No 404 here.At this point, it really feels like it’s a GitHub Actions cache thing, even though I can’t find where such thing is configured (I’m not very familiar with the actions/toolkit repo).
Anyone still having this issue after pinning the version and has additional thoughts or suggestions?
Just as an FYI, I opened an issue on the kubectl issue tracker (https://github.com/kubernetes/kubernetes/issues/121400). Maybe some release update failed and now the stable.txt contains a version that doesn’t correspond to a binary.
That’s why default doesn’t work, although it should probably use the fallback version specified in the script, and it just fails rather than using the fallback which would alleviate some pain points since all of my projects don’t specify a pinned version.
I could make the PR that fixes the fallback version, but not sure if the authors see that as an issue.