Automate helm chart artifacts reference publish on release

[MaxBab]

Is this the right place to submit this?

• [X] This is not a question about how to use the sail-operator

Feature Description

As per now, Sail Operator helm charts could be installed by using helm repo add helm-sail-operator https://istio-ecosystem.github.io/sail-operator/ flow without a need to clone the repository. In gh-pages branch, an "index.yaml" file holds a reference to the helm artifact attached to a release asset.

The next step is to automate "index.yaml" file update during each release, so it will always contain the reference to the new helm artifact version.

Additional Information

No response

[MaxBab]

@dgn @bmangoen

Hi Daniel, Brian,

Could you share your opinion on the following, please? Please, read the issue description for the context.

I would like to add an automation flow to release github action, so the "index.yaml" file will be updated with each new helm artifact release. Since, we would like to keep the identical sha hash of the helm artifact archive, I thought to add the following flow:

• Once the gh release is published, download the artifact from the release assets.
• Run helm command to update the "index.yaml" file, which will generate a metadata and provide a link to the assets archive of helm artifact.
• Push the "index.yaml" file to gh-pages branch to update it.

Everything sound pretty simple. But there is one issue that could complex it.

I saw that the release workflow has, by default, a parameter of "draft", which performs the release as draft and not publishing it until manual approval. The problem with it comes with the artifact link which is temporary and unusable.

For example: Release assets link for helm artifact looks like that: https://github.com/istio-ecosystem/sail-operator/releases/download/0.1.0/sail-operator-0.1.0.tgz

But a link of the draft release, looks like that: https://github.com/istio-ecosystem/sail-operator/releases/download/untagged-f0cb177e5849ddd3fa8f/sail-operator-0.1.1.tgz

So, it means that until the release will not be published, I can't really know or presume the assets link, so I can't use it for both download the assets artifact or reference it within the "index.yaml" file.

Of course I can do the workflow separate from the release workflow, but I would like to find a way to make less manual work, by triggering two separate workflows.

So, my questions are:

• Are we planning to create each release as draft release first?
• Maybe we could create some condition that waits for the release to be published and then it will move to publish the helm artifact.
• Or maybe you're ok with having two separate workflows?

Appreciate your thoughts on that. Thanks.

[bmangoen]

Hey,

I think we made the draft release the default to avoid creating releases accidentally. I guess we only manually promoted from a draft to a release for the first release Sail Operator 0.1.0-rc.1 but the next ones shouldn't be released as a draft.

@dgn how did you do for Sail Operator 0.1.0 ?

[bmangoen]

Or maybe you're ok with having two separate workflows?

I'm not against having another workflow which could be triggered when a release is published.

[dgn]

If we can have a workflow that is triggered by the actual creation and publishing of a release, which then goes and updates the index.yaml, that'll work for me. It might make sense to create a PR with the change instead of pushing directly, which would e.g. give us the option to later add a test (which e.g. verifies that all URLs in index.yaml are indeed reachable). Even if we create a PR, we can configure CI so that it's merged automatically after all tests have passed.

[MaxBab]

@bmangoen @dgn

Thanks for your response.

If we can have a workflow that is triggered by the actual creation and publishing of a release, which then goes and updates the index.yaml, that'll work for me.

As I mentioned above, that will work if the release will be published right away and not created as draft. Otherwise, it will not be able to fetch the url for the artifact.

Let's do the following. I'll start working on a separate workflow to update the index.yaml file according to the published release. And once we will see that our release is stable and do not need to be created as draft, I'll merge that new workflow into the release workflow.

Will it work for you?

[dgn]

Yeah, I think a separate workflow is fine. IIUC, we can have it be triggered by the publishing of the release, no need to change the existing workflow.

[MaxBab]

That's a good idea, to trigger by publish. Will check it.

Thanks.