[IGNORE]: automate release preparation by vprashar2929 · Pull Request #382 · perses/perses-operator

vprashar2929 · 2026-04-19T07:44:14Z

Description

This commit adds a .github/workflows/release.yaml workflow that prepares a release by:

Writing a new version to VERSION file
Running make bundle VERSION_REPLACED=<prev> to regenerate the OLM bundle with the correct spec.replaces chain
Running make build-installer to regenerate the bundle.yaml
Opening a PR against main with the changes

The commit also updates the existing RELEASE.md with the new flow

Closes: #ISSUE-NUMBER

Type of change

FEATURE (non-breaking change which adds functionality)
ENHANCEMENT (non-breaking change which improves existing functionality)
BUGFIX (non-breaking change which fixes an issue)
BREAKINGCHANGE (fix or feature that would cause existing functionality to not work as expected)
DOC (documentation only)
IGNORE (tooling, build system, CI, etc.)

Verification

Unit tests added/updated
Integration tests added/updated
E2E tests added/updated
Manual testing performed

Checklist

Pull request has a descriptive title and context useful to a reviewer
Code follows project conventions and passes linting
All commits have DCO signoffs

vprashar2929 · 2026-04-20T04:52:39Z

CI run for ref: vprashar2929#1

vprashar2929 · 2026-04-20T05:02:33Z

+    (`spec.version`, `spec.replaces`)
+  - CRDs and jsonnet generated files (if CRDs changed)
+  - `bundle.yaml` (root installer manifest)
+- If CHANGELOG updates are needed, run `make generate-changelog` locally and


@jgbernalp @slashpai The current workflow doesn't run make generate-changelog Just want to confirm should we include it as part of the workflow in which workflow runs make generate-changelog and then we edit the PR to cleanup UNKNOWN entries before we merge it or do we want to do it manually after the PR is merged to main?

I think it makes sense to let the workflow generate the changelog and clean it up in the PR.

Agreed, I will make the change and we can review the changelog in the release PR.

jgbernalp · 2026-04-20T07:24:04Z

Just to confirm, we are changing the flow so we don't have to create a release/vX.Y branch and we just review the PR as all the generation, changelog and tag can be done from the CI. Is that correct?

vprashar2929 · 2026-04-21T08:13:36Z

Just to confirm, we are changing the flow so we don't have to create a release/vX.Y branch and we just review the PR as all the generation, changelog and tag can be done from the CI. Is that correct?

Correct so we no longer need to create a release/vX.Y branch for release preparation. The release workflow handles updating the VERSION, generating changelog, generating bundle and installer manifests and opens a PR against main branch which we review and update/clean any UNKNOWN changelog entries before we merge.

Currently I didn't automate tag creation so that is done manually. Would you prefer keeping it manual or should we automate that as well?

jgbernalp · 2026-04-23T08:13:54Z

+    inputs:
+      tag:
+        description: "New version to release, e.g. 0.4.0 (no 'v' prefix)"
+        required: true


can we add validation on these format to avoid errors?

jgbernalp · 2026-04-23T08:16:51Z

+    permissions:
+      contents: write
+      pull-requests: write
+    steps:


Suggested change

steps:

concurrency:

group: release-preparation

cancel-in-progress: true

steps:

jgbernalp · 2026-04-23T08:17:57Z

+      - name: Checkout
+        uses: actions/checkout@v6
+        with:
+          fetch-depth: 0


does the changelog depend on having the commits?

yes I think we need it

slashpai · 2026-04-27T08:36:36Z

+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+      pull-requests: write


why we need this permission? its an elevated permission IIUC

Nice catch! 🙇 yes we don't need them. Pushed the change for that

This commit adds a `.github/workflows/release.yaml` workflow that prepares a release by: - Writing a new version to `VERSION` file - Running `make bundle VERSION_REPLACED=<prev>` to regenerate the OLM bundle with the correct `spec.replaces` chain - Running `make build-installer` to regenerate the `bundle.yaml` - Opening a PR against `main` with the changes The commit also updates the existing `RELEASE.md` with the new flow Signed-off-by: vprashar2929 <vibhu.sharma2929@gmail.com>

slashpai · 2026-04-29T07:52:23Z

@@ -1,83 +1,127 @@
 # Perses Operator Release

-## 1. Prepare your release


Do we need to remove all these steps? These are independent of operator hub, I think like helm chart section we should have a section for operatorhub instead

Yes these are all handled by the workflow now

slashpai · 2026-04-29T07:56:46Z

ok I realized this is different PR :)

Also a couple of questions:

For changelog update we need to verify if pr numbers are correct and skip unknown types. We use the script currently and release shepherd reviews it manually and corrects if needed. So if a PR is created by bot again we will need to update if issues IIUC.
curious to know if you have tested this in fork

vprashar2929 · 2026-05-08T06:10:04Z

For changelog update we need to verify if pr numbers are correct and skip unknown types. We use the script currently and release shepherd reviews it manually and corrects if needed. So if a PR is created by bot again we will need to update if issues IIUC.

The workflow just runs make generate-changelog as how we do currently in other workflow. Once the PR is created we need to review the generated changelog and then push the corrected change back to the generated PR: https://github.com/perses/perses-operator/pull/382/changes#diff-2b1b69303b927a484e02c7fad9fc87d0d3ff0dc22ae1da0ecd0dc935d922a23cR62

vprashar2929 · 2026-05-08T06:13:56Z

curious to know if you have tested this in fork

Yep I tested on my fork. Here is the workflow run: https://github.com/vprashar2929/perses-operator/actions/runs/24709425948 along with PR generated: vprashar2929#1
That PR has the full output:

VERSION bumped to 0.3.3
Changelog generated (CHANGELOG.md) and ready for UNKNOWN cleanup in PR review
Bundle generated with VERSION_REPLACED=0.3.2 (OLM replaces: perses-operator.v0.3.2)
Installer manifest bundle.yaml generated

vprashar2929 commented Apr 20, 2026

View reviewed changes

vprashar2929 marked this pull request as ready for review April 20, 2026 05:02

vprashar2929 requested a review from a team as a code owner April 20, 2026 05:02

vprashar2929 force-pushed the ci-release-auto branch 2 times, most recently from 6ce7c46 to 694f520 Compare April 21, 2026 07:18

vprashar2929 force-pushed the ci-release-auto branch from 694f520 to 7daec69 Compare April 21, 2026 14:32

jgbernalp mentioned this pull request Apr 23, 2026

Automate releases and operator hub submissions #380

Open

jgbernalp reviewed Apr 23, 2026

View reviewed changes

Comment thread .github/workflows/release.yaml Outdated

jgbernalp reviewed Apr 23, 2026

View reviewed changes

vprashar2929 force-pushed the ci-release-auto branch from 7daec69 to d454305 Compare April 27, 2026 08:34

slashpai reviewed Apr 27, 2026

View reviewed changes

vprashar2929 force-pushed the ci-release-auto branch from d454305 to 4e2f723 Compare April 27, 2026 08:42

vprashar2929 force-pushed the ci-release-auto branch from 4e2f723 to 30b3f10 Compare April 29, 2026 06:04

slashpai requested changes Apr 29, 2026

View reviewed changes

-    steps:
+    concurrency:
+      group: release-preparation
+      cancel-in-progress: true
+    steps:

		@@ -1,83 +1,127 @@
		# Perses Operator Release

		## 1. Prepare your release

Conversation

vprashar2929 commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Type of change

Verification

Checklist

Uh oh!

vprashar2929 commented Apr 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jgbernalp commented Apr 20, 2026

Uh oh!

vprashar2929 commented Apr 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slashpai commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vprashar2929 commented May 8, 2026

Uh oh!

vprashar2929 commented May 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vprashar2929 commented Apr 19, 2026 •

edited

Loading

slashpai commented Apr 29, 2026 •

edited

Loading