feat: create helm chart repository in gh-pages

[patrickleet]

Fixes #1851 and fixes #1881

Also requested in #751, #914, #1525,

Proposed Changes

This publishes a gh-pages branch as a helm repo for the package.

You will need to go to repo settings and enable it (Settings -> Pages):

I cherry picked @kromanow94's commits from #1851 but they got squashed out. I modified that script, moved it to hack/, created a go template to render HTML from the index.yaml file, and added a github workflow that handles all of that.

It runs on every push to main but only commits to gh-pages if there are differences, which only happens when y'all release.

This allows users to use Helm chart via:

helm repo add knative-operator https://knative.github.io/operator
helm show values knative-operator/knative-operator

Release Note

NONE

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: patrickleet / name: Patrick Lee Scott (e002926)

[knative-prow]

Welcome @patrickleet! It looks like this is your first PR to knative/operator 🎉

[knative-prow]

Hi @patrickleet. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[patrickleet]

example: https://patrickleet.github.io/knative-operator/

helm repo add patrickleet-knative-operator https://patrickleet.github.io/knative-operator
helm show values patrickleet-knative-operator/knative-operator

[patrickleet]

perhaps a better trigger than push to main could be used

maybe on tag published

on:
  push:
    tags:
    - *

but it wouldn't run until there was a new tag that way

[kromanow94]

Amazing!

[patrickleet]

@houshengbo you still the person to tag to review this?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.88%. Comparing base (dc2f488) to head (e002926).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1931   +/-   ##
=======================================
  Coverage   63.88%   63.88%           
=======================================
  Files          54       54           
  Lines        2622     2622           
=======================================
  Hits         1675     1675           
  Misses        830      830           
  Partials      117      117           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[houshengbo]

@patrickleet Thanks for the contribution. Could you first rebase this PR on the main branch?
Could you also add some doc instructing us how we can use it?
Do we really have to create another branch for this repo?

[patrickleet]

Do we really have to create another branch for this repo?

have to - no, worth doing so - I think so.

gh-pages is a special branch in Github to host static sites - so therefore the index.yaml file can be used more easily.

The file could be kept in main, but that adds the responsibility to main of being a helm repository as well, and it's triggered on push to main, so that could cause the action to run, commit, and run again. gh-pages is a new branch without any history of the project to be clear.

The user experience is better with gh pages, imo

helm repo add knative-operator https://knative.github.io/operator
helm show values knative-operator/knative-operator

vs

helm repo add knative-operator https://raw.githubusercontent.com/knative/operator/main
helm show values knative-operator/knative-operator

The index.html file that's served in gh-pages wouldn't work at all in main which is a nicer user experience for seeing what's available in the repository.

[patrickleet]

@houshengbo rebased

[patrickleet]

where would you like to add

helm repo add knative-operator https://knative.github.io/operator
helm show values knative-operator/knative-operator
helm install knative-operator --namespace knative-operator --create-namespace knative-operator/knative-operator

to the docs - seems they aren't in this repo? https://knative.dev/docs/install/operator/knative-with-operators/ would make the most sense

[patrickleet]

I just want to point out that people have been asking for this for nearly 3 and half years - myself included, I've been using knative for years - being able to install it like every other tool I use would be fantastic

[patrickleet]

Added PR for docs knative/docs#6158

[patrickleet]

rebased again

[houshengbo]

@patrickleet The only thing I need to do to cut a new release is to create a new branch named release-1.xx from the main branch. I am not sure how we can kick off the helm chart publish by doing that. Is there any manual work involved to generate and publish the helm chart?

[patrickleet]

@houshengbo I have it set up to run on every commit to main

https://github.com/knative/operator/pull/1931/files#diff-8b1ace8ae125f8756835c097d7d4aed77d4f56b640a2311adb6d132ab821c392R3-R6

The script checks the knative operator releases and builds the index.yaml file based on what's in there. So if the script is run, and nothing has changed since the last time, the same file will be generated.

The script checks if there any diffs using git, and only commits to gh-pages if there has been changes, which only happens when there is a new release.

So this would kick off the next time a commit to main happened after you released.

Wouldn't be manual work, really, just a waiting period, which isn't ideal. Probably running when a tag is added is best, I'm not sure if release is an event type or not - on tag for sure is.

[patrickleet]

@houshengbo

Ok, yea, looks like there are release triggers

on:
  release:
    types: [published]

should do the trick.

https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release

I'll make an update.

[houshengbo]

@patrickleet Thanks for the work, would you mind doing one more rebased? I would like to approve it.

[patrickleet]

@houshengbo rebased!

[patrickleet]

I see @dprotaso set up a gh-pages branch yesterday

[houshengbo]

/lgtm
/approve

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: houshengbo, patrickleet

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [houshengbo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[houshengbo]

@patrickleet That's per my request.