No release since v3.14.0: dependabot bumps in main are not reaching users

Hi!

We use the `quay.io/helmpack/chart-testing` image in GitLab CI for a repo with 145 charts, so this matters for us a bit.

Last release is v3.14.0 from 2025-10-08, and the image on quay was built the same day (`latest` points to the same build). Since then main got 38 commits and 35 of them are dependabot bumps. None of that reaches anyone who installs ct or pulls the image.

Looks like the reason is that `release.yaml` runs on `workflow_dispatch` with a version typed by hand. So the tooling is all there, goreleaser included, and the only missing part is someone pressing the button.

The image also ships helm v3.16.4 from that build. We had to replace the binary on our side to lint charts with the helm our clusters actually run. Trivy on the v3.14.0 image shows 152 HIGH / 7 CRITICAL, and 52 of those are in that bundled helm.

Few questions:

- Is a release planned, even just to ship what is already in main?
- Is the helm inside the image meant to follow helm releases, or is it pinned on purpose?
- Any plans for helm 4? #854 asks the same and got no answer, so not sure the issue was seen.
- What is the state of the project in general?

If maintainers are short on time, I would like to help. Things I could prepare:

- release automation so the bumps ship by themselves, for example release-please opening a release PR from the commits, leaving you only the merge. Your goreleaser setup stays as is.
- `CONTRIBUTING.md`, and a `MAINTAINERS`/`OWNERS` file. Right now there is no contributing guide and no list of who to ask, which makes it hard to tell whether the project is waiting for help or just quiet.
- `AGENTS.md`/`CLAUDE.md`, since a lot of contributions come through coding agents now and they do better with the build and test commands written down. Related: is there a policy on AI assisted contributions? I use one and would rather follow your rules than guess.

I will not open unsolicited PRs. If any of this sounds useful, say which and I will prepare it, otherwise I am happy to just wait.

Thanks for the tool, it works good for us.

Start with release.yaml and its workflow_dispatch trigger, then inspect the existing goreleaser setup. The issue proposes several possible efforts—release automation, CONTRIBUTING.md, MAINTAINERS/OWNERS, and agent guidance—so first confirm which scope maintainers want. Done should be a specifically agreed change with a clear release or documentation outcome.

Written by the indexing model from the issue text.