Move release logic to a new workflow

[mgoerens]

• remove steps creating the GitHub release from "build.yaml" workflow.
• add steps to tag the main branch with the version tag after an
  automerge in the "build.yaml" workflow.
• create a new GitHub Action for handling GitHub release on new tags on
  main.
• modify the python script handling the release to be able to get the
  release body directly.

fixes #380

[mgoerens]

@komish This is ready for another round of review.

I've tested in this repo: https://github.com/mgoerens/my-chart-verifier. It's an almost one to one copy of the chart-verifier repo, in particular in terms of GitHub workflows. If there is any scenario you want to check we can do so there. I've tested in particular:

• Creating a standard PR (not a release): Run the tests but doesn't automerge / tag/
• Creating a release pipeline: Run the tests + automerge + tag
• Upon tagging of the main branch: create the release + tarball
• Delete tag: Release becomes Draft release
• Create tag manually: triggers creation of release + tarball

A few notes:

• As mentioned, this allows the recreation of a GitHub release and its associated assets (currently only tarball, later also container image) by manually deleting and recreating the tag (git -d 1.12.2 && git push --delete origin 1.12.2 && git tag 1.12.2 && git push --tags)
• In that case however, the tests are not run. Also the "old" release is not completely deleted but continues to live as a Draft. It needs to be manually cleaned up.
• In the build.yaml workflow, the steps which tags the main branch is run using a Personal Access Token (currently set to PTA_MGOERENS, but that secret doesn't exist in this repo). This is because by default, a GitHub Workflow cannot trigger another GitHub Workflow. See https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

[mgoerens]

Here's an example release PR in mgoerens/my-chart-verifier: mgoerens/my-chart-verifier#3

The associated Workflow runs:

• in the PR (note this is red because I haven't configured the appropriate Build triggers on Quay.io for this image, but the failure happens after the PR is merged and master is tagged): https://github.com/mgoerens/my-chart-verifier/actions/runs/5626007182/job/15246830087
• on master after automatic tagging: https://github.com/mgoerens/my-chart-verifier/actions/runs/5626464345

And the release it created: https://github.com/mgoerens/my-chart-verifier/releases/tag/1.13.0

[mgoerens]

@komish The pipeline is failing though I only pushed some comments since last Friday.

There are errors such as:

Error running chart install: rendered manifests contain a resource that already exists. Unable to continue with install: Service "psql" in namespace "charts-382" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "psql-service-0tcqxs7pvz": current value is "psql-service-wldcqgu59a"

I suspect this is because I pushed two times to the branch within a few seconds, triggering two pipeline to run in parallel and conflict (trying to deploy similar charts in similar namespaces for instance). Could that be ? Does our workflow allow parallel run ?

[komish]

@mgoerens it likely is a conflict if the same chart happened to be installed at the same time. Multiple pipeline runs can occur because things happen in namespaced contexts. I'll take a look at the underlying cluster here shortly.

[komish]

Suggested change

	github_token: ${{ secrets.PAT_MGOERENS }}
	github_token: ${{ secrets.GITHUB_TOKEN }}

[mgoerens]

Sorry I'm a bit too verbose sometimes, I mentioned in a previous comment:

In the build.yaml workflow, the steps which tags the main branch is run using a Personal Access Token (currently set to PTA_MGOERENS, but that secret doesn't exist in this repo). This is because by default, a GitHub Workflow cannot trigger another GitHub Workflow. See https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

So I believe we must use a Personal Access Token. We'll have to create the secret in this repo before merging (before we cut a new release). I'm happy to rename it to something else than PAT_MGOERENS though.

[komish]

Just so I'm clear, when you say this can be manually triggered, you mean by creating a tag?
In other words, there's no workflow_dispatch event that this triggers on, and that's normally what I see when a workflow can be manually triggered.

[mgoerens]

That's correct, it can be triggered manually by manually creating a tag on the main branch with the right format (x.x.x without leading v).

It's not intended to be triggered manually via the GitHub GUI / CLI.

I'll reword the comment.

[komish]

Looking good overall. I want to do a few more tests and look over your repo before I mark this approved.
The only other thing I can think of that might be problematic is the dev release. Just want to make sure that's doing what I think it should even after these changes.

[komish]

/lgtm

[komish]

Looks great. We'll need to review the next "release" that includes changes to chart-verifier itself to make sure everything looks as we expect.