Deployment code block doesn't filter alpha releases

[relaxdiego]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:

When deploying KubeVirt using the code block provided in the quick start guides, alpha releases aren't filtered.

What you expected to happen:

When deploying using the sample code blocks, only stable releases are deployed.

Anything else we need to know?:

Sample code block that doesn't filter alpha releases:

export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | grep tag_name | grep -v -- '-rc' | sort -r | head -1 | awk -F': ' '{print $2}' | sed 's/,//' | xargs)

Suggested alternate code block to filter alpha releases, assuming all tag_names are SemVer compliant:

export VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | grep tag_name | grep -v -- '-.*$' | sort -r | head -1 | awk -F': ' '{print $2}' | sed 's/,//' | xargs)

Affected guides:

1. https://kubevirt.io/quickstart_kind/
2. https://kubevirt.io/quickstart_cloud/

[cwilkers]

By the time I come to test some code, v0.59.0 is released, so no more rcs at the top of the list. When an alpha release/candidate was at the top, was it also latest? As in, if you add "/latest" to the end of the URL in the curl, was it still pointing to an RC? If so, I think I have an all awk way to handle this. (I'm writing install instructions in a different guide.)

curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | awk -F '[ \t":]+' '$2 =="tag_name" && $3 ~ /^[^-]+$/ {print $3;exit 0}'

I mean, if we're going to be using awk anyway, let's really use awk :-)

[JM1]

@cwilkers atm the latest release is v0.60.0-alpha.0. Regarding your /latest question:

$ curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name
  "tag_name": "v0.59.0",

$ curl -s https://api.github.com/repos/kubevirt/kubevirt/releases | grep tag_name
    "tag_name": "v0.60.0-alpha.0",
    "tag_name": "v0.59.0",
    "tag_name": "v0.59.0-rc.2",
    ...

[cwilkers]

Let's use /latest then, any objections?

Now we should gather a list of locations using this code so we can be sure to fix it across the board (no old blogs, though)

In this repo, it looks like:

_includes/quickstarts/virtctl.md labs/kubernetes/lab3.md pages/quickstart_cloud.md pages/quickstart_kind.md pages/quickstart_minikube.md

In user-guide: docs/operations/installation.md docs/operations/updating_and_deletion.md docs/operations/virtctl_client_tool.md

It will also be good to update the Killercoda scenarios in kubevirt/katacoda-scenarios

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[JM1]

/remove-lifecycle stale

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[JM1]

/remove-lifecycle stale

[cwilkers]

More recently (and actually that means going back four months), I have been seeing blogs using a much simpler artifact to get the most recent stable release:

curl https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt

and to consume it:

export RELEASE=$(curl https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)

All in favor? With this much simpler version PRs to add this in should be greatly simplified.