-
Notifications
You must be signed in to change notification settings - Fork 317
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
Add CD for helm charts #199
Conversation
Thanks for the help! I have not used this action in the past. How does it manage the versions? |
This action will attach packaged helm charts (tgz) to whatever GitHub release you create in the UI. When a release is (pre)released, the action checks out that commit/tag, and runs |
@ddelange Got it. Thanks for the explanation. That means we need to enable it in release branch (e.g. release-0.2 etc ) and I am also thinking whether we should bump chart version with main release version or keep it separate. |
@@ -18,13 +18,14 @@ version.BuildInfo{Version:"v3.6.2", GitCommit:"ee407bdf364942bcb8e8c665f82e15aa2 | |||
|
|||
To avoid duplicate CRD definitions in this repo, we reuse CRD config in `ray-operator`: | |||
```console | |||
$ kubectl apply -k "../../ray-operator/config/crd" | |||
$ kubectl apply -k "github.com/ray-project/kuberay/ray-operator/config/crd?ref=v0.3.0" |
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.
ref=v0.3.0
is something I am confusing, current HEAD TAG is v0.2.0. Before we cut v0.3.0, I think this is invalid?
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.
0.3.0 was intentional here and below, in preparation of the upcoming tag that will support this functionality. I guess you could also point this one to master
and the tgz links below to latest
(with some dirty ol' grepping or so ref https://stackoverflow.com/q/24987542), but for helm related stuff, immutable tags are generally recommended
I think as long as this action lives on the default branch, it doesn't matter from which branch the release is triggered: the commit that the tag points to will be checked out. Regarding chart verioning: most projects I've seen run independent semantic versioning on their chart. E.g. cluster-autoscaler for a long time synced versions, but then decided against it and started running separate semver |
Co-authored-by: ddelange <14880945+ddelange@users.noreply.github.com>
* Create release.yaml * Update kuberay-operator docs * Update ray-cluster docs * Prepare for 0.3.0 * Prepare for 0.3.0 * Update helm-chart/kuberay-operator/README.md Co-authored-by: ddelange <14880945+ddelange@users.noreply.github.com> Co-authored-by: Jiaxin Shan <seedjeffwan@gmail.com>
Why are these changes needed?
Allows running helm (e.g. in Terraform) without having to clone this repo
Related issue number
Ported from ray-project/ray#22799
Checks