LCORE-1720: Description of the release process#1737
Conversation
WalkthroughThis PR adds a new docs page describing Lightspeed Core release organization: Konflux application/branch mapping, ReleasePlan/RPA-driven promotion controls, Comet customer-facing image/tag contract, and step-by-step workflows and checklists for micro and minor releases. ChangesRelease Organization Documentation
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/release-organization.md`:
- Around line 134-140: The ordered list under the "How to create the `Release`"
section has inconsistent numbering (items 1,2,3 where nested/subitems should use
consistent auto-numbering); update the markdown so all ordered lists use a
single style (prefer using "1." for every list item to leverage Markdown
auto-numbering) for the block that references `ReleasePlan`, `Release`, and
`Snapshot` and for the subsequent section (4.3) so numbering is consistent
throughout; ensure nested bullets remain either dashed or numbered consistently
and verify the Konflux UI/kubectl mention stays as a list item under the same
list.
- Line 17: Several occurrences in the document use mixed/mismatched markdown
markers like **ReleasePlan`** which break rendering; search for the identifiers
ReleasePlan and ReleasePlanAdmission and replace each malformed instance with
the correct markdown form depending on intent (bold code: **`ReleasePlan`**,
bold text: **ReleasePlan**, or inline code: `ReleasePlan`); update all listed
lines (and any other similar occurrences) so the opening and closing backticks
and asterisks match for consistent rendering.
- Line 98: The release note for the RC tag is confusing because it shows
x.y.z"rcZZ" with embedded quotes; update the sentence that references `x.y.zrcN`
to remove stray quotes and clearly show incorrect vs correct forms (e.g., show
the incorrect example as x.y.z"rcZZ" or "x.y.z-rcZZ" and then the intended
correct form as **x.y.zrcZZ**), replacing the current fragment `x.y.z"rcZZ"`
with an explicit clarification and the bolded correct form `x.y.zrcZZ` so
readers can unambiguously see the intended RC tag notation.
- Line 216: Add a single trailing newline character at the end of the document
that contains the sentence "If internal Konflux YAML or Comet bundle sources
live in other repositories, link them here once their locations are fixed so
this document stays the single narrative entry point." — open that file and
ensure it ends with exactly one newline (no extra blank lines).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2d63af4b-4a8f-4aea-a4aa-701f7b2411b0
📒 Files selected for processing (1)
docs/release-organization.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (15)
- GitHub Check: mypy
- GitHub Check: spectral
- GitHub Check: Pylinter
- GitHub Check: integration_tests (3.12)
- GitHub Check: build-pr
- GitHub Check: unit_tests (3.13)
- GitHub Check: unit_tests (3.12)
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: library mode / ci / group 2
- GitHub Check: E2E: library mode / ci / group 1
- GitHub Check: E2E Tests for Lightspeed Evaluation job
- GitHub Check: E2E: server mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 2
- GitHub Check: E2E: library mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 1
🧰 Additional context used
🪛 LanguageTool
docs/release-organization.md
[style] ~62-~62: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...add a new Konflux application for a new minor release branch, you add a **new `Releas...
(EN_ADJ_ORDER)
[style] ~79-~79: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...this registry path.” When you add a new minor release branch or change RC/GA tagging,...
(EN_ADJ_ORDER)
[style] ~144-~144: Consider using a different verb for a more formal wording.
Context: ...your RPA allows. If the pipeline fails, fix the underlying issue, obtain or wait fo...
(FIX_RESOLVE)
[style] ~165-~165: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...* (§2.2–§2.3). ### 4.3 Minor releases (new minor branch, e.g. 0.7) A minor bump (e....
(EN_ADJ_ORDER)
🪛 markdownlint-cli2 (0.22.1)
docs/release-organization.md
[warning] 140-140: Ordered list item prefix
Expected: 1; Actual: 3; Style: 1/1/1
(MD029, ol-prefix)
[warning] 148-148: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 175-175: Ordered list item prefix
Expected: 1; Actual: 3; Style: 1/2/3
(MD029, ol-prefix)
[warning] 177-177: Ordered list item prefix
Expected: 2; Actual: 4; Style: 1/2/3
(MD029, ol-prefix)
[warning] 179-179: Ordered list item prefix
Expected: 3; Actual: 5; Style: 1/2/3
(MD029, ol-prefix)
[warning] 182-182: Ordered list item prefix
Expected: 1; Actual: 6; Style: 1/2/3
(MD029, ol-prefix)
[warning] 184-184: Ordered list item prefix
Expected: 2; Actual: 7; Style: 1/2/3
(MD029, ol-prefix)
[warning] 185-185: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 201-201: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 216-216: Files should end with a single newline character
(MD047, single-trailing-newline)
|
|
||
| ## 2. Konflux | ||
|
|
||
| Konflux groups Lightspeed Core work by **Application** (one per minor release branch), **component** builds inside that application, and **release** wiring: a `**ReleasePlan`** per application in the developer tenant, paired with **ReleasePlanAdmission (RPA)** in the managed tenant so promotions land on the right `registry.redhat.io` paths and tags. |
There was a problem hiding this comment.
Fix markdown formatting: mismatched bold and backtick markers.
Line 17 contains **ReleasePlan**` which has mismatched formatting markers. This pattern appears throughout the document (lines 26, 27, 30, 52, 58, 60, 121, 130, 136, 138, 140, 148, 170, 172, 176, 178, 180, 181, 183, 185, 192, 193, 194, 201, 203, 208, 209) and will cause incorrect rendering.
Correct patterns:
- For bold code:
**\ReleasePlan`**` - For just bold:
**ReleasePlan** - For just code:
\ReleasePlan``
Example fix for line 17
-Konflux groups Lightspeed Core work by **Application** (one per minor release branch), **component** builds inside that application, and **release** wiring: a `**ReleasePlan`** per application in the developer tenant, paired with **ReleasePlanAdmission (RPA)** in the managed tenant so promotions land on the right `registry.redhat.io` paths and tags.
+Konflux groups Lightspeed Core work by **Application** (one per minor release branch), **component** builds inside that application, and **release** wiring: a **`ReleasePlan`** per application in the developer tenant, paired with **ReleasePlanAdmission (RPA)** in the managed tenant so promotions land on the right `registry.redhat.io` paths and tags.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Konflux groups Lightspeed Core work by **Application** (one per minor release branch), **component** builds inside that application, and **release** wiring: a `**ReleasePlan`** per application in the developer tenant, paired with **ReleasePlanAdmission (RPA)** in the managed tenant so promotions land on the right `registry.redhat.io` paths and tags. | |
| Konflux groups Lightspeed Core work by **Application** (one per minor release branch), **component** builds inside that application, and **release** wiring: a **`ReleasePlan`** per application in the developer tenant, paired with **ReleasePlanAdmission (RPA)** in the managed tenant so promotions land on the right `registry.redhat.io` paths and tags. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/release-organization.md` at line 17, Several occurrences in the document
use mixed/mismatched markdown markers like **ReleasePlan`** which break
rendering; search for the identifiers ReleasePlan and ReleasePlanAdmission and
replace each malformed instance with the correct markdown form depending on
intent (bold code: **`ReleasePlan`**, bold text: **ReleasePlan**, or inline
code: `ReleasePlan`); update all listed lines (and any other similar
occurrences) so the opening and closing backticks and asterisks match for
consistent rendering.
|
|
||
| - [Konflux: Creating a release](https://konflux.pages.redhat.com/docs/users/releasing/create-release.html) — selecting a Snapshot and creating a `Release` (§4.1). | ||
|
|
||
| If internal Konflux YAML or Comet bundle sources live in other repositories, link them here once their locations are fixed so this document stays the single narrative entry point. No newline at end of file |
There was a problem hiding this comment.
Add trailing newline at end of file.
Files should end with a single newline character per standard conventions.
Proposed fix
If internal Konflux YAML or Comet bundle sources live in other repositories, link them here once their locations are fixed so this document stays the single narrative entry point.
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| If internal Konflux YAML or Comet bundle sources live in other repositories, link them here once their locations are fixed so this document stays the single narrative entry point. | |
| If internal Konflux YAML or Comet bundle sources live in other repositories, link them here once their locations are fixed so this document stays the single narrative entry point. | |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 216-216: Files should end with a single newline character
(MD047, single-trailing-newline)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/release-organization.md` at line 216, Add a single trailing newline
character at the end of the document that contains the sentence "If internal
Konflux YAML or Comet bundle sources live in other repositories, link them here
once their locations are fixed so this document stays the single narrative entry
point." — open that file and ensure it ends with exactly one newline (no extra
blank lines).
syedriko
force-pushed
the
syedriko-lcore-1720
branch
from
87e3a6d to
f32f1bb
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (1)
docs/release-organization.md (1)
17-18:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winFix malformed bold/code markdown markers across the document.
Several instances still use broken combinations like
`**ReleasePlan`**/**x.y.zrcN** /**release/0.6**, which render incorrectly. Use one consistent form per intent (e.g.,ReleasePlan,release/0.6, or release/0.6).Also applies to: 33-33, 37-37, 205-205, 213-215, 230-230, 243-243, 282-285
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/release-organization.md` around lines 17 - 18, The document contains malformed mixed bold/code markers (e.g., `` `**ReleasePlan`** ``, `**x.y.zrcN`** , `**release/0.6`**) that render incorrectly; open docs/release-organization.md and replace each occurrence with a consistent style: use backticks for code elements like `release/0.6` and `x.y.zrcN` (matching src/version.py), and bold plain text for names like **ReleasePlan** or **release/0.6** if you intend emphasis; fix the listed instances (lines around the shown diff and also at the other locations noted: 33, 37, 205, 213-215, 230, 243, 282-285) so every symbol (ReleasePlan, release/<major>.<minor>, x.y.zrcN, src/version.py) uses either `code` or **bold** consistently, not both.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/release-organization.md`:
- Line 5: The heading "### Roles used in this document" is currently H3 but
should be H2 to fix the hierarchy; change that line to "## Roles used in this
document" so the document flows from H1 to H2 correctly and maintains proper
Markdown heading levels.
- Line 239: The document contains contradictory branch guidance: the sentence
that currently reads "Git: Follow your team's tag or release-branch policy on
the correct branch (`release/0.5` for 0.5.x, `main` for 0.6.x)" conflicts with
the later statement that "0.6.1 commits are on `release/0.6`"; make these
consistent by updating the Git guidance to match the model described in §2.1
(e.g., state that 0.6.x patch releases are cut from `release/0.6` rather than
`main`, or alternately update the later example to indicate patches come from
`main` if §2.1 intends that), and ensure both the paragraph containing "Git:
Follow your team's tag or release-branch policy..." and the example mentioning
"0.6.1 commits are on `release/0.6`" use the same branch policy and add a
one-sentence pointer to §2.1 for the canonical policy.
---
Duplicate comments:
In `@docs/release-organization.md`:
- Around line 17-18: The document contains malformed mixed bold/code markers
(e.g., `` `**ReleasePlan`** ``, `**x.y.zrcN`** , `**release/0.6`**) that render
incorrectly; open docs/release-organization.md and replace each occurrence with
a consistent style: use backticks for code elements like `release/0.6` and
`x.y.zrcN` (matching src/version.py), and bold plain text for names like
**ReleasePlan** or **release/0.6** if you intend emphasis; fix the listed
instances (lines around the shown diff and also at the other locations noted:
33, 37, 205, 213-215, 230, 243, 282-285) so every symbol (ReleasePlan,
release/<major>.<minor>, x.y.zrcN, src/version.py) uses either `code` or
**bold** consistently, not both.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: ba69e6d6-7a3e-4b5d-a141-d155dca24a2e
📒 Files selected for processing (1)
docs/release-organization.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: bandit
- GitHub Check: spectral
- GitHub Check: unit_tests (3.13)
- GitHub Check: build-pr
- GitHub Check: unit_tests (3.12)
- GitHub Check: Pylinter
- GitHub Check: E2E: library mode / ci / group 1
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: library mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 2
- GitHub Check: E2E: server mode / ci / group 1
- GitHub Check: E2E: library mode / ci / group 2
- GitHub Check: E2E: server mode / ci / group 3
- GitHub Check: E2E Tests for Lightspeed Evaluation job
🧰 Additional context used
🪛 LanguageTool
docs/release-organization.md
[style] ~87-~87: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...dds a new Konflux application for a new minor release branch, they must also add a **...
(EN_ADJ_ORDER)
[style] ~154-~154: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...this registry path." When you add a new minor release branch or change RC/GA tagging,...
(EN_ADJ_ORDER)
[uncategorized] ~240-~240: The official name of this software platform is spelled with a capital “H”.
Context: ...ns (Quay)**: If you push a git tag, .github/workflows/build_and_push_release.yaml ...
(GITHUB)
[style] ~249-~249: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...* (§2.2-§2.3). ### 4.3 Minor releases (new minor branch, e.g. 0.7) A minor bump (e....
(EN_ADJ_ORDER)
[uncategorized] ~273-~273: The official name of this software platform is spelled with a capital “H”.
Context: ...wn cadence. 8. GitHub Actions The .github/workflows/build_and_push_release.yaml ...
(GITHUB)
[uncategorized] ~297-~297: The official name of this software platform is spelled with a capital “H”.
Context: ...lication via GitHub Actions is desired (.github/workflows/build_and_push_release.yaml)...
(GITHUB)
[style] ~307-~307: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...ery). ### 5.2 Minor release checklist (new minor branch) Use this when opening a new mi...
(EN_ADJ_ORDER)
[uncategorized] ~321-~321: The official name of this software platform is spelled with a capital “H”.
Context: ...es cover 0.7-* tag patterns. - Verify .github/workflows/build_and_push_release.yaml ...
(GITHUB)
[uncategorized] ~345-~345: The official name of this software platform is spelled with a capital “H”.
Context: ...componentTags | | GitHub Actions (.github/workflows/build_and_push_release.yaml)...
(GITHUB)
[uncategorized] ~348-~348: The official name of this software platform is spelled with a capital “H”.
Context: ...kflow also has a dev image variant (.github/workflows/build_and_push_dev.yaml) tha...
(GITHUB)
🪛 markdownlint-cli2 (0.22.1)
docs/release-organization.md
[warning] 5-5: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
[warning] 76-76: Blank line inside blockquote
(MD028, no-blanks-blockquote)
[warning] 215-215: Ordered list item prefix
Expected: 1; Actual: 3; Style: 1/1/1
(MD029, ol-prefix)
[warning] 230-230: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 263-263: Ordered list item prefix
Expected: 1; Actual: 4; Style: 1/2/3
(MD029, ol-prefix)
[warning] 265-265: Ordered list item prefix
Expected: 2; Actual: 5; Style: 1/2/3
(MD029, ol-prefix)
[warning] 267-267: Ordered list item prefix
Expected: 3; Actual: 6; Style: 1/2/3
(MD029, ol-prefix)
[warning] 270-270: Ordered list item prefix
Expected: 1; Actual: 7; Style: 1/2/3
(MD029, ol-prefix)
[warning] 272-272: Ordered list item prefix
Expected: 2; Actual: 8; Style: 1/2/3
(MD029, ol-prefix)
[warning] 274-274: Ordered list item prefix
Expected: 3; Actual: 9; Style: 1/2/3
(MD029, ol-prefix)
[warning] 275-275: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 359-359: Files should end with a single newline character
(MD047, single-trailing-newline)
|
|
||
| This document describes how Konflux **Applications**, **ReleasePlans**, **components**, **ReleasePlanAdmission (RPA)**, the Comet (catalog) container images, and release practice fit together, and how to perform **micro** and **minor** releases. | ||
|
|
||
| ### Roles used in this document |
There was a problem hiding this comment.
Fix heading level increment at the start of the document.
The document jumps from H1 (Line 1) to H3 (Line 5). Promote Line 5 to H2 for valid hierarchy.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 5-5: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/release-organization.md` at line 5, The heading "### Roles used in this
document" is currently H3 but should be H2 to fix the hierarchy; change that
line to "## Roles used in this document" so the document flows from H1 to H2
correctly and maintains proper Markdown heading levels.
| Typical flow: | ||
|
|
||
| 1. **Version bump**: Update `src/version.py` to the target version (e.g. `__version__ = "0.6.1"` or `__version__ = "0.6.0rc1"`). Commit and push to the correct branch. CI validates the version string via `pdm show --version`. | ||
| 2. **Git**: Follow your team's tag or release-branch policy on the correct branch (`release/0.5` for 0.5.x, `main` for 0.6.x). |
There was a problem hiding this comment.
Resolve contradictory branch guidance for 0.6 patch releases.
Line 239 says 0.6.x ships from main, while Line 282 says 0.6.1 commits are on release/0.6. This can send operators to cut a patch from the wrong branch.
Proposed doc fix (align with current model shown in §2.1)
-| 0.6.1 patch | Bump `version.py` to `0.6.1`; commits on `release/0.6` | Keep `lightspeed-core-0.6` | Same component names; revision still **that release branch** | **RPA:** add `0.6.1` tag -> **Snapshot** -> `**Release`** (§4.1) |
+| 0.6.1 patch | Bump `version.py` to `0.6.1`; commits on `main` | Keep `lightspeed-core-0.6` | Same component names; revision still `main` | **RPA:** add `0.6.1` tag -> **Snapshot** -> `Release` (§4.1) |Also applies to: 282-282
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/release-organization.md` at line 239, The document contains
contradictory branch guidance: the sentence that currently reads "Git: Follow
your team's tag or release-branch policy on the correct branch (`release/0.5`
for 0.5.x, `main` for 0.6.x)" conflicts with the later statement that "0.6.1
commits are on `release/0.6`"; make these consistent by updating the Git
guidance to match the model described in §2.1 (e.g., state that 0.6.x patch
releases are cut from `release/0.6` rather than `main`, or alternately update
the later example to indicate patches come from `main` if §2.1 intends that),
and ensure both the paragraph containing "Git: Follow your team's tag or
release-branch policy..." and the example mentioning "0.6.1 commits are on
`release/0.6`" use the same branch policy and add a one-sentence pointer to §2.1
for the canonical policy.
1 participant
Description
Description of the release process
Type of change
Tools used to create PR
Identify any AI code assistants used in this PR (for transparency and review context)
Related Tickets & Documents
Checklist before requesting a review
Testing
Summary by CodeRabbit