Meshery: [CI] Incorporate creation and publishing of Meshery Helm chart into stable release workflow

[leecalcote]

Current Behavior

• Location of source code for Meshery’s chart: https://github.com/layer5io/meshery/tree/master/install/kubernetes/helm/meshery
• Location of published Meshery chart: https://github.com/layer5io/meshery.io/tree/master/charts (used by Artifact Hub)
• No workflow included in the build and release CI workflow for publishing the helm chart.

Desired Behavior

1. The Helm chart should be incorporated into the stable release channel.
2. The Helm chart should follow Meshery’s versioning.

Implementation

• No workflow included in the build and release CI workflow for publishing the helm chart.

Acceptance Tests

1. Meshery's helm chart is updated and published with each Meshery stable version release.
2. Meshery's helm chart no longer has its own version number, but follows that of Meshery (server).

_Future:_

1. Users can use mesheryctl system channel to switch between release channels. // @anirudhjain75 @navendu-pottekkat

[leecalcote]

Related to https://github.com/layer5io/meshery/discussions/1792#discussion-29007

[leecalcote]

Example of where we have automated the build and release of Helm charts in Learn-Layer5 - https://github.com/layer5io/learn-layer5/blob/43e1dc9563c4232bed341cbf076c9561367ff040/.github/workflows/ci.yml#L46-L64

[Aisuko]

Example of where we have automated the build and release of Helm charts in Learn-Layer5 - https://github.com/layer5io/learn-layer5/blob/43e1dc9563c4232bed341cbf076c9561367ff040/.github/workflows/ci.yml#L46-L64

Looks good, sir. But I have a consider on this, as the description of this Github Action

https://lippertmarkus.com/2020/08/13/chartreleaser/

When you now push a change to your master branch, the action checks each chart for a new version. For updated charts it creates a GitHub Release and adds the chart artifact *.tgz file to the release. Now the index.yaml file on the gh-pages branch is updated to add your new chart version with the link to the GitHub Releases artifact.

This CI should be work in the repo which only includes the source code of Helm charts right?

[leecalcote]

The secrets are already in place. You just need to reference them in a workflow like what is being done in this Layer5 repo.

On Jan 25, 2021, at 7:47 PM, Aisuko [e-mail] wrote:


Example of where we have automated the build and release of Helm charts in Learn-Layer5 - https://github.com/layer5io/learn-layer5/blob/43e1dc9563c4232bed341cbf076c9561367ff040/.github/workflows/ci.yml#L46-L64

Looks good, sir. But I do not have permission to setup the Secret in any repo in Layer5, there may need some's help on it.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Aisuko]

I have a consider on this

https://lippertmarkus.com/2020/08/13/chartreleaser/

When you now push a change to your master branch, the action checks each chart for a new version. For updated charts it creates a GitHub Release and adds the chart artifact *.tgz file to the release. Now the index.yaml file on the gh-pages branch is updated to add your new chart version with the link to the GitHub Releases artifact.

This CI should be work in the repo which only includes the source code of Helm charts right?

[leecalcote]

You can build from source in one repo and push build artifact to another repo.

On Jan 26, 2021, at 1:55 AM, Aisuko [e-mail] wrote:


I have a consider on this

https://lippertmarkus.com/2020/08/13/chartreleaser/

When you now push a change to your master branch, the action checks each chart for a new version. For updated charts it creates a GitHub Release and adds the chart artifact *.tgz file to the release. Now the index.yaml file on the gh-pages branch is updated to add your new chart version with the link to the GitHub Releases artifact.

This CI should be work in the repo which only includes the source code of Helm charts right?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[leecalcote]

@ramrodo, this is a good item to review in the Meshery CI Meeting this Thursday.

[ramrodo]

Added to the agenda 👍🏼

[ramrodo]

One question @Aisuko, are you currently working on this?. I want to help if it is possible but I don't understand well what we should do. For instance, you mention:

This CI should be work in the repo which only includes the source code of Helm charts right?

I think that yes. We should implement this CI workflow in the same repo that the Helm Charts source code is.

I have a consider on this
https://lippertmarkus.com/2020/08/13/chartreleaser/

Yes. It's a good idea to use that GitHub Action to publish the chart releases into a Github Page and also, it'll allow us to add the .tgz to the Github release published 👍🏼

[Aisuko]

Hi, @ramrodo I mean this Github Action for Helm chart release tool is good for us. But I believe this tool would work well for the repo which only includes the Helm chart source code. Everything we committing should be aiming at Helm Charts. And the Github Action can release the new charts with bumped version.

If we add this Github Action to the Meshery repo, the workflows I believe is like, we merge any commit not even though it did not include the change of the chart, we although release the new version charts right? This may not make any sense.

[ramrodo]

@Aisuko ok, I see the problem you are pointing out. So, if we want to use that GitHub Action, we should separate the code of the charts to a new repo, right? Have another repo like "meshery-charts", right?

[Aisuko]

@Aisuko ok, I see the problem you are pointing out. So, if we want to use that GitHub Action, we should separate the code of the charts to a new repo, right? Have another repo like "meshery-charts", right?

Yes, you got this. @leecalcote Hello, sir. Any idea on this?

[leecalcote]

@Aisuko, yes, I wrote up a set of thoughts on this a few weeks ago and lost them when my browser crashed. Here's the very short version:

• users that are serious about having Meshery help them run their service measures are most likely to be running mastery in Kubernetes. Making sure that this Meshery deployment experience is highly curated and smooth is important. To facilitate this, having the Helm chart published much more frequently will help ensure that it's up to speed. It didn't (and maybe still doesn't?) have all of the adapters in it. We are retiring the Octarine adapter, so that needs updated. The point is that changes occur here some frequency.
• Our CI workflows include much conditional logic today. Some of the that logic is based on whether files in a path are changed (e.g. only publish new version of the chart when changes to the chart files are made).
• The Meshery repo has many components in it (ui, cli, database, docs and so on). We do this because people measure a project based on number of stars and number of contributions. We need to optimize where those signals live (we need them in the same core repo to the extent possible). The helm chart is another one of those components.

I propose that we work to integrate conditional flow for publishing Meshery's helm chart using the same release version number as Meshery. Agreeable?

[leecalcote]

@ramrodo do you have any objections here? Let's move forward?

[Aisuko]

@Aisuko, yes, I wrote up a set of thoughts on this a few weeks ago and lost them when my browser crashed. Here's the very short version:

* users that are serious about having Meshery help them run their service measures are most likely to be running mastery in Kubernetes. Making sure that this Meshery deployment experience is highly curated and smooth is important. To facilitate this, having the Helm chart published much more frequently will help ensure that it's up to speed. It didn't (and maybe still doesn't?) have all of the adapters in it. We are retiring the Octarine adapter, so that needs updated. The point is that changes occur here some frequency.

* Our CI workflows include much conditional logic today. Some of the that logic is based on whether files in a path are changed (e.g. only publish new version of the chart when changes to the chart files are made).

* The Meshery repo has many components in it (ui, cli, database, docs and so on). We do this because people measure a project based on number of stars and number of contributions. We need to optimize where those signals live (we need them in the same core repo to the extent possible). The helm chart is another one of those components.

I propose that we work to integrate conditional flow for publishing Meshery's helm chart using the same release version number as Meshery. Agreeable?

For sure, I got your point right now. You are right, we need the contributor to focus on our main project(Especially the situation of us). If we release a new version of Meshery; We should release the new version of Helm charts. So, we need to change the image tag from latest to the specially version.

[ramrodo]

@leecalcote Sure! Sounds really good. We're on the same page. We can proceed with this.