Uses GitHub API and agent variables to keep the SDK up-to-date
Details
It was getting painful to keep the version of the Replicated SDK up-to-date in
the labs built to support the Builders experience. Right now we don't have
releases for the SDK but we do tag each version. This change uses the GitHub
API to get the latest version of the SDK (based on the tags). It then sets that
variable into an agent variable and uses it in both lifecycle scripts and
track instructions.
There is one place that still has a hard-coded SDK values: the asset that is
used to populate the static URL for the support bundle in "Closing the
Information Gap." We still don't have continuous deliver of that file the the
GCP bucket, so I'm going to defer solving the versioning issue until we
implement that. I'm not terribly concerned with it falling out of date for now,
since it is checking image pull permissions and those are going to be set at
the repository level.
TL;DR
Uses GitHub API and agent variables to keep the SDK up-to-date
Details
It was getting painful to keep the version of the Replicated SDK up-to-date in the labs built to support the Builders experience. Right now we don't have releases for the SDK but we do tag each version. This change uses the GitHub API to get the latest version of the SDK (based on the tags). It then sets that variable into an agent variable and uses it in both lifecycle scripts and track instructions.
There is one place that still has a hard-coded SDK values: the asset that is used to populate the static URL for the support bundle in "Closing the Information Gap." We still don't have continuous deliver of that file the the GCP bucket, so I'm going to defer solving the versioning issue until we implement that. I'm not terribly concerned with it falling out of date for now, since it is checking image pull permissions and those are going to be set at the repository level.