🚀 Helm Chart publish using Github Pages and actions

[mhkarimi1383]

Closes #67

[tiagolobocastro]

Does this publish the release as well right?
How do we manage when to bump the chart version? On the other openebs repos we now do this via release branches, rather than develop, allowing for some more automated and manual testing before actually releasing.

[mhkarimi1383]

Yeah

[mhkarimi1383]

Can you give me some example for that?

[mhkarimi1383]

We can mark versions as pre (with a suffix) when it's not running on a tag
Or when running on a branch other than develop

[tiagolobocastro]

The automation is here: https://github.com/openebs/zfs-localpv/blob/develop/.github/workflows/branch_preparation.yml
The chart publish here: https://github.com/openebs/zfs-localpv/blob/2a0e29a820e4c107e509ae2be9a03cdae3753b54/.github/workflows/release.yml#L210

[mhkarimi1383]

For that we have to refactor the entire CI pipelines that are related to build/publish to follow the branching that we want

[tiagolobocastro]

Alright, let's do this simple approach for now and introduce branching strategy later on.
But meanwhile, am I correct to assume as soon as this is merged a new release v0.9.0 would be done? And if so, do we want to do that now, or is there anything else we might want to do before releasing that? (nothing I can think of as of now, asking just in case)

[mhkarimi1383]

I wasn't able to rebase because of conflicts :(

[tiagolobocastro]

You need to resolve the conflicts when rebasing, especially since you're renaming files, you don't want to miss changes.
Maybe do the rename on a separate PR and just do the chart publish on this one?

[mhkarimi1383]

You need to resolve the conflicts when rebasing, especially since you're renaming files, you don't want to miss changes.
Maybe do the rename on a separate PR and just do the chart publish on this one?

Yeah, but it's a bit hard since I'm creating my PRs from my own fork

In this PR I wanted to make the helm chart file structure the same as other projects and provided the yams installation option

[tiagolobocastro]

You need to resolve the conflicts when rebasing, especially since you're renaming files, you don't want to miss changes.
Maybe do the rename on a separate PR and just do the chart publish on this one?

Yeah, but it's a bit hard since I'm creating my PRs from my own fork

In this PR I wanted to make the helm chart file structure the same as other projects and provided the yams installation option

I think should be fine as long as you squash when merging this

[tiagolobocastro]

Alright, let's do this simple approach for now and introduce branching strategy later on.
But meanwhile, am I correct to assume as soon as this is merged a new release v0.9.0 would be done? And if so, do we want to do that now, or is there anything else we might want to do before releasing that? (nothing I can think of as of now, asking just in case)

[mhkarimi1383]

@tiagolobocastro

Yeah, but before that we have to merge the fstype I think

Also I have created the first version of json schemas that I can push them to this branch :)

[mhkarimi1383]

After that I will change the helm-docs template to include how to install helm chart using the repository

[mhkarimi1383]

Before the release we have to also bump up the version of the project itself and create a tag from it to publish the image and bump up app version here

[mhkarimi1383]

Sorry for spamming commits, It was a bit hard to solve conflict, will squash commits when merging with develop

[tiagolobocastro]

I think we can remove the cache, it's not doing anything at the moment and if triggers warnings in the files

[mhkarimi1383]

Yeah, let's remove that in another PR :)

[mhkarimi1383]

If I merge this, It will create a helm chart related release

So, we have to do the left things that I said or merge?