Add CI via GitHub Actions

[colearendt]

What this PR does / why we need it:

Add CI:

• lint/test
  • lint changed charts
  • then lint all charts
  • run kind (these are allowed to fail)
  • install changed charts
  • install all charts
• release (on main, see if any new chart versions - if so, GitHub release and update the index.yaml on the gh-pages branch)
• rebuild (rebuilds the index.yaml file from GitHub release history)

Some open items to discuss here:

• how do we do this in such a way that it does not affect your current setup? Should we create a gh-pages branch to maintain the "new" index.yaml on until you want to cut over the definition of GitHub pages? Will that affect anything?
• should we remove the "changed vs. all" components of the action? It is most useful when there is more than one chart in a repo. Which side should we err on? Only run lint/test when there are changes? Always run them (even on docs PRs?)
• are any of the dependencies concerning? Of note:
  • azure/setup-helm
  • actions/checkout
  • peter-evans/create-pull-request
  • helm/chart-releaser-action, helm/chart-testing-action, helm/kind-action
• we also have an action that we use to code-generate README.md (to keep documentation up to date with the values.yaml file) via helm-docs. Is this something that would be interesting to you?
• are there any arguments to linting and testing that would be helpful? i.e. --upgrade maybe? The goal of separating here was to allow preventing installation if lint fails https://github.com/apache/couchdb-helm/blob/bd9bce1a54cebd85448ff620e79ed0f64d18a7b4/test/e2e-kind.sh#L64

Which issue this PR fixes

(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

• fixes #62

Special notes for your reviewer:

Checklist

(removed: NA)

[willholley]

Thanks for the PR @colearendt - it generally looks good to me. On the discussion points:

how do we do this in such a way that it does not affect your current setup? Should we create a gh-pages branch to maintain the "new" index.yaml on until you want to cut over the definition of GitHub pages? Will that affect anything?

I think this is right, and should be a safe change for existing users:

• create a new gh-pages branch
• merge this PR
• backfill releases via #79
• update .asf.yaml to switch GH pages over to the new gh-pages branch
• after switch over confirmed, remove docs from main branch

should we remove the "changed vs. all" components of the action?

If the change detection is reliable then I'm happy to go with linting changes only

are any of the dependencies concerning?

They all look well used/maintained, so no concerns from me.

we also have an action that we use to code-generate README.md (to keep documentation up to date with the values.yaml file) via helm-docs. Is this something that would be interesting to you?

Yes - that sounds helpful!

are there any arguments to linting and testing that would be helpful? i.e. --upgrade maybe?

I think testing with --upgrade makes sense as we do today. This has caught a few issues for us in the past.

[colearendt]

TIL about .asf.yaml! Nice!

I have made the discussed changes:

• run lint-only changes on branches (still running all on main because there are never any changes otherwise. Testing/linting on main still seems desirable). It is pretty simple to revert this at some point, and is low cost/fast anyways if you did want to lint always. One benefit of running based on changed/always is consistency with the install checks
• Add --upgrade flag to ct install tests

One last idea:

• wanted to make sure that push to main and pull_request is the right definition for triggers. i.e. pushing to a random branch will not trigger CI unless a PR is created. IIRC one of the problems of just using "push to any branch" was that it did not trigger CI for remote PRs, and having both "all branches" and "PR"s would trigger duplicate CI runs on PRs.

[willholley]

run lint-only changes on branches (still running all on main because there are never any changes otherwise. Testing/linting on main still seems desirable).

It seems like if we do this we should also require linear history (we can set in .asf.yaml)

wanted to make sure that push to main and pull_request is the right definition for triggers

That seems right to me.

+1