Re-factor fluent-operator release process

[joshuabaird]

Problem

The current release process for fluent-operator is time consuming and contains lots of manual steps. Roughly, the process currently is:

1. Create a new release-3.x-work branch starting at master
2. Update CHANGELOG.md by manually generating a draft Github Release and then manually re-formatting
3. Update README.md
4. Update RELEASE.md
5. Open a PR for the release-3.x-work branch into master
6. Cut a release-3.x brancgh starting at the merge commit of the release-3.x-work branch
7. Update VERSION
8. Generate manifests using make manifests and manually update image tags
9. Push the release-3-x branch
10. Generate and push new tag for release
11. Draft a new Github Release
12. Manually attach setup.yaml to the release
13. Review/merge PR's

Potential Solution

In this issue, we're proposing an entirely new process for cutting releases of fluent-operator. The goal for the re-factor is to introduce a simpler, automated process for releasing. At the core, this proposal uses release-please + conventional commits to automate much of the release process:

• On every push to master, release-please automatically opens/updates a "release PR" containing the version bump, updated CHANGELOG.md, bumped Chart.yaml appVersion entries, and updated image tag references
• When you're ready to ship: merge the Release PR
• release-please pushes the tag and creates the GitHub Release automatically
• The existing build-op-image.yaml fires on the tag as today
• A new upload-release-assets.yaml builds and attaches setup.yaml to the release

What This Eliminates

Previously needed	With release-please
release-tool.yaml dispatch	Gone — Release PR is auto-maintained
publish-release.yaml dispatch	Gone — merging the Release PR = publish
release-drafter for CHANGELOG	Gone — release-please generates it
Manual git tag + git push	Gone — automatic on merge
Manual GitHub Release creation	Gone — automatic on merge

Flow

flowchart TD
    A["PRs merge to master normally"] --> B["release-please auto-updates\nRelease PR on each merge\n(VERSION, CHANGELOG, Chart.yaml bumped)"]
    B --> C["Maintainer reviews Release PR\n(edit CHANGELOG if needed)"]
    C --> D["Merge Release PR"]
    D --> E["release-please pushes tag v3.8.0\n+ creates GitHub Release"]
    E --> F["build-op-image.yaml\n(existing, fires on tag)"]
    E --> G["New: upload-release-assets.yaml\nbuilds + uploads setup.yaml"]
    H["pr-title-lint.yaml\n(blocks merge if title invalid)"] --> A

Loading

What to build?

1. release-please workflow + config

• New: .github/workflows/release-please.yaml — runs googleapis/release-please-action@v4 on every push to master
• New: .github/release-please-config.json — sets release-type: simple, configures extra-files to bump:
  • VERSION
  • charts/fluent-operator/Chart.yaml (appVersion)
  • charts/fluent-operator/charts/fluent-bit-crds/Chart.yaml (appVersion, version)
  • charts/fluent-operator/charts/fluentd-crds/Chart.yaml (appVersion, version)
  • Image tag references in manifests/setup/setup.yaml and manifests/setup/fluent-operator-deployment.yaml
• New: .github/.release-please-manifest.json — tracks the current released version (e.g. {"." : "3.7.0"})
  Versioning model: release-please parses conventional commit prefixes from squash-merge commit messages (i.e. PR titles) to categorize the CHANGELOG and determine the version bump automatically. The release-as input allows a maintainer to pin a specific version when the auto-calculated one isn't right.

2. PR title enforcement

• New: .github/workflows/pr-title-lint.yaml — runs amannn/action-semantic-pull-request@v6 (pinned to SHA) on pull_request_target events; posts a sticky PR comment via marocchino/sticky-pull-request-comment explaining exactly what's wrong when validation fails, auto-deletes when it passes
• New: .github/PULL_REQUEST_TEMPLATE.md — one-liner reminder of the format with a link to the Conventional Commits spec
• Repo setting (one-time): enable "Default to PR title for squash merge commits" — individual commit messages inside a PR do not need to follow the convention, only the PR title
• Branch protection (one-time): make pr-title-lint a required status check on master

3. upload-release-assets.yaml

• Trigger: on: release: types: [published]
• Checks out the tag, runs make manifests to regenerate setup.yaml with the correct image tag, uploads it to the release via gh release upload
• Permissions: contents: write

4. Retire release-tool.yaml

The existing .github/workflows/release-tool.yaml is superseded. Delete it.

Not in scope

I'm not currently putting the "sync helm chart to the helm-charts repo" in scope for this plan.

[joshuabaird]

@marcofranssen @cw-Guo Could you please review this and leave some comments?

I'm not necessarily tied to anything laid out here -- but, I do believe we need to simplify our release process, and this is just one idea for doing so.

POC draft PR: #1950