Set up gh pages helm repository generation

[DaltheCow]

I made a gh-pages branch, which looking at here: https://github.com/runatlantis/helm-charts/tree/gh-pages
It would seem like could have been an empty branch, not sure if that matters.

The chart-releaser-action should generate the index.yaml that is needed for the helm repository. This is almost identical to their example release.yaml: https://github.com/helm/chart-releaser-action?tab=readme-ov-file#example-workflow

Atlantis has a few differences: https://github.com/runatlantis/helm-charts/blob/main/.github/workflows/release.yaml

Can we use this renovate thing? # renovate: datasource=github-tags depName=helm packageName=helm/helm

I think we need that or some alternative to be able to use git tags to manage releases and stuff based off of my research so hopefully that works easily

[tdg5]

As I suggested elsewhere, what do you think about moving this from an auto-triggered action to an action that's triggered by workflow dispatch?

Suggested change

	on:
	push:
	branches:
	- main
	paths:
	- 'charts/nm-vllm/**'
	on:
	workflow_dispatch:
	inputs:
	version:
	description: 'Release version'
	required: true
	default: '1.2.3'

(from pytest's release workflow)

[tdg5]

Having though about this more, I don't think we can pick our versions like this and life will be most simple if we track versions in the various Chart.yaml directly.

Suggested change

	on:
	push:
	branches:
	- main
	paths:
	- 'charts/nm-vllm/**'
	on:
	workflow_dispatch:

[tdg5]

Oof, I'm a mess. Now I'm back to thinking we should include a version in the workflow since versions of different charts won't agree anyway. We'd have release version separate from chart versions I guess?

Suggested change

	on:
	push:
	branches:
	- main
	paths:
	- 'charts/nm-vllm/**'
	on:
	workflow_dispatch:
	inputs:
	version:
	description: 'Release version'
	required: true
	default: '1.2.3'

[tdg5]

Renovate seems cool, but I don't think it's something we need at this point. I'm open to argument though

Suggested change

# renovate: datasource=github-tags depName=helm packageName=helm/helm

[tdg5]

I'd suggest using our automation user

Suggested change

	git config user.name "$GITHUB_ACTOR"
	git config user.email "$GITHUB_ACTOR@users.noreply.github.com"
	git config user.name "nm-automation"
	git config user.email "automation@neuralmagic.com"

though that doesn't work so great later when this is open source and someone forks the repo

So what if instead we add some config to the repo for the release actor and we can fallback to the github actor if the config isn't set... That'd look something like this I think

Suggested change

	git config user.name "$GITHUB_ACTOR"
	git config user.email "$GITHUB_ACTOR@users.noreply.github.com"
	RELEASE_ACTOR_NAME_FROM_REPO="${{ vars.RELEASE_ACTOR_NAME }}"
	RELEASE_ACTOR_EMAIL_FROM_REPO="${{ vars.RELEASE_ACTOR_EMAIL }}"
	RELEASE_ACTOR_NAME="${RELEASE_ACTOR_NAME_FROM_REPO:-$GITHUB_ACTOR}"
	RELEASE_ACTOR_EMAIL="${RELEASE_ACTOR_EMAIL_FROM_REPO:-$GITHUB_ACTOR@users.noreply.github.com}"
	git config user.name "$RELEASE_ACTOR_NAME"
	git config user.email "$RELEASE_ACTOR_EMAIL"

[tdg5]

We name our secrets differently in these parts... Maybe we can do the same kind of thing as we did with RELEASE_ACTOR and try our preferred config first and fallback to the broader default. I'm led to believe we might be able to do that like this?

Suggested change

	CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
	CR_TOKEN: "${{ secrets.CICD_GITHUB_PAT || secrets.GITHUB_TOKEN || secrets.CR_TOKEN }}"

Not sure if that works for secrets, but it works for some things it would seem.