-
Notifications
You must be signed in to change notification settings - Fork 34
Just build from the latest version #117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though I wonder whether we might prefer to preserve the flexibility enabled by the build arg .. ?
In other words, we could just remove the publish_${major}_${minor} drone steps and leave the GCLOUD_SDK_TAG build arg implementation unchanged.. Seems that would achieve the objective of this PR (always building / publishing from latest upstream alpine) without impacting our ability to easily build (and publish) from other base images.. some example uses cases:
- programmatically build multiple versions locally to aid with the debugging / testing of upstream releases
- build / publish a
drone-gke:slimvariant from the upstream'sslimvariant that selectively preinstalls additional components (via it'sINSTALL_COMPONENTSbuild arg) for user's with non-alpine requirements - build / publish a
drone-gke:debugvariant from the upstream'slatestvariant to include the kitchen sink of preinstalled components (e.g., for experimenting w/krewplugins that interact with non-gke APIs) - etc..
i don't feel too strongly either way, just figured i'd mention it!
|
Sounds good, kept that in. |
README.md
Outdated
| The last two-three minor releases are supported ([same as GKE](https://cloud.google.com/kubernetes-engine/versioning-and-upgrades)). | ||
| Since the [237.0.0 (2019-03-05) Google Cloud SDK][sdk], the container image contains multiple versions of `kubectl`. | ||
| The corresponding client version that matches the cluster version will be used automatically. | ||
| This follows the minor release support that ([GKE offers](https://cloud.google.com/kubernetes-engine/versioning-and-upgrades)). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are the parentheses around GKE offers intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right it's not.
|
whoops sorry about the double approve |
No need to specify which version of the SDK since the original intent was to support multiple
kubectlversions at the same time (see #90).Thought about this as I was preparing to tag a release.