Open bewing opened 1 year ago
@bewing: This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted
label.
The triage/accepted
label can be added by org members by writing /triage accepted
in a comment.
A bunch of us tried to reproduce this during today's bug scrub and we were not able to. Can you please confirm whether you are still experiencing this issue?
/triage needs-information
I am still experiencing this issue.
Here is a gist with the full output from executing the script with -x set: https://gist.github.com/bewing/62f50954a6a8cb9e6ca1e3c6a100fcb7
The machine in question is colocated with ServerCentral in Chicago, IL
As additional information: This is non-deterministic. Once, it did manage to download/install the binary successfully. I think Github or its cache might be doing some A/B testing of removing newlines from API output?
Curious if in your testing performing curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases
generates the output as one extremely long line, or as multi-line?
$ curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases | wc -l
0
edit:
again, this is non-deterministic. I tried again just now and got the multi-line response:
$ curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases | wc -l
3572
If newlines are not present, adding jq
into the invocation can restore them, and make this work properly:
# non-working
curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases | grep browser_download.*linux_amd64 | cut -d '"' -f 4 | sort -V | tail -n 1
https://api.github.com/repos/kubernetes-sigs/kustomize/releases/73452880
# working
$ curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases | jq | grep browser_download.*linux_amd64 | cut -d '"' -f 4 | sort -V | tail -n 1
https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v4.5.7/kustomize_v4.5.7_linux_amd64.tar.gz
I'm also seeing this problem only recently. It definitely worked a few days ago. In my case it's on macos.
+ tar xzf './kustomize_v*_darwin_arm64.tar.gz'
tar: Error opening archive: Failed to open './kustomize_v*_darwin_arm64.tar.gz'
The pipe to jq
workaround works for me.
So should we modify the script to use jq
? What's the current status here?
So should we modify the script to use jq? What's the current status here?
I'm not sure. How can you ensure that jq
is present? It looks like the current script tries very hard to use only common binaries (curl, cut, grep). Adding in a new dependency might break a lot of things downstream (operator-sdk, for example) that attempt to use this script o install kustomize for build steps if not present in the path
That's a good point. Maybe finding a solution without adding an additional dependency would be the best way forward.
Maybe json_pp
is common enough to use?
curl -s https://api.github.com/repos/kubernetes-sigs/kustomize/releases | json_pp -json_opt pretty,canonical | grep browser_download.*linux_amd64 | cut -d '"' -f 4 | sort -V | tail -n 1
Indeed, we want to avoid introducing extra dependencies to this script. Although I'd also prefer to avoid adding complexity, if we have no better option, we could check if the most commonly available tool is present, and continue attempting to use the output raw if it isn't (perhaps with a warning message).
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle-stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
/remove-lifecycle-rotten
Ping @bewing
Haven't thought about this in a bit. Might the best approach be to:
https://api.github.com/repos/kubernetes-sigs/kustomize/releases
, store it as a variable, and test its line lengthgrep --only-matching
(is this considered portable enough?)The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen
/remove-lifecycle rotten
@bewing: Reopened this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen
/remove-lifecycle rotten
@bewing: Reopened this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Describe the bug It seems like a change in how GitHub API text is returned is causing issues with the bash script
hack/install_kustomize.sh
. Instead of pretty printing the JSON output, it is returned as a single line. As a result, the incorrect download link is selected ( there is only a single line for grep to search, it returns it as true as the pattern is in that line, and cut selects the wrong URL for download). PlatformTested on Ubuntu 20.04.4 LTS with curl 7.68.0
Additional context
Some output from
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash -xs -- 3.8.7 ~/bin
(taken from operator SDK Makefile)If I download
install_kustomize.sh
and modify the script to pass the output from the release_url through| jq .
to pretty-print it, it works as expected.