LCORE-1720: Description of the release process#1737
Conversation
Walkthrough
ChangesKonflux Release Organization Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
🚥 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
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.
tisnik
left a comment
tisnik
left a comment
There was a problem hiding this comment.
LGTM in overall, but would it be possible to merge this doc into https://github.com/lightspeed-core/lightspeed-stack/blob/main/docs/releasing.md ?
TYVM
syedriko
force-pushed
the
syedriko-lcore-1720
branch
from
f32f1bb to
65dd788
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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/releasing.md`:
- Line 183: The "Conventions" heading is incorrectly at level #### directly
under the "Konflux" (##) section; update the heading text "Conventions" to use a
single-step deeper level (### Conventions) to restore proper markdown hierarchy
and fix TOC/anchor issues, and then regenerate or re-check the table of contents
if your build process requires it.
- Around line 18-36: TOC anchor fragments are incorrect and don’t match the
generated heading IDs; update each TOC link so the fragment exactly matches the
markdown-generated slug for its heading (e.g., change the top-level
"`#release-organization`" to the slug for the actual heading "Konflux release
organization", update "Konflux" and nested items like "Applications and
components", "ReleasePlan per application and connection to RPA", and longer
headings such as "Comet (container catalog): what users pull" and "Snapshot
selection and creating a `Release` for an Application" to their exact generated
anchors), applying the same correction pattern to all nested entries so every
fragment equals the heading text’s slug (respecting lowercase,
punctuation/character removal, spaces -> hyphens rules).
🪄 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: fe938741-0f3d-4ab8-85a5-f8057580b31f
📒 Files selected for processing (1)
docs/releasing.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: unit_tests (3.13)
- GitHub Check: unit_tests (3.12)
- GitHub Check: mypy
- GitHub Check: Pylinter
- GitHub Check: spectral
- GitHub Check: build-pr
- GitHub Check: E2E Tests for Lightspeed Evaluation job
- GitHub Check: E2E: server mode / ci / group 2
- GitHub Check: E2E: server mode / ci / group 3
- GitHub Check: E2E: library mode / ci / group 1
- GitHub Check: E2E: library mode / ci / group 2
- GitHub Check: E2E: server mode / ci / group 1
- GitHub Check: E2E: library mode / ci / group 3
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
🧰 Additional context used
🪛 LanguageTool
docs/releasing.md
[style] ~31-~31: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...atch-and-rc) * [Minor releases (new minor branch, e.g. 0.7)](#43-minor-releases-n...
(EN_ADJ_ORDER)
[style] ~34-~34: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...rc) * [Minor release checklist (new minor branch)](#52-minor-release-checklist-ne...
(EN_ADJ_ORDER)
[style] ~58-~58: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ty in a backwards-compatible manner. * Increment PATCH when you make backwards-compatibl...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~95-~95: Consider a more concise word here.
Context: ... that is stored in docs/openapi.json. In order to do it, run the following command: ```b...
(IN_ORDER_TO_PREMIUM)
[style] ~95-~95: Consider a more expressive alternative.
Context: ...red in docs/openapi.json. In order to do it, run the following command: ```bash...
(DO_ACHIEVE)
[grammar] ~112-~112: Ensure spelling is correct
Context: ...s are deleted (the latest are hidden on Unit systems!) ### Build the distribution a...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~126-~126: Use a hyphen to join words.
Context: ...ion}-py3-none-any.whl ``` Please double check that the {version} really contai...
(QB_NEW_EN_HYPHEN)
[style] ~127-~127: Consider using a different verb to strengthen your wording.
Context: ...the correct version number. Also please make sure that the archive was really built to av...
(MAKE_SURE_ENSURE)
[grammar] ~170-~170: Ensure spelling is correct
Context: ... ### Update link in README.md At the beggining of README.md there's a line: ```text...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~255-~255: 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] ~322-~322: 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] ~408-~408: 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] ~417-~417: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...asePlan` / RPA**. #### Minor releases (new minor branch, e.g. 0.7) A minor bump (e....
(EN_ADJ_ORDER)
[uncategorized] ~441-~441: 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] ~465-~465: 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] ~475-~475: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...covery). #### Minor release checklist (new minor branch) Use this when opening a new mi...
(EN_ADJ_ORDER)
[uncategorized] ~489-~489: 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] ~513-~513: 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] ~516-~516: 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/releasing.md
[warning] 18-18: Link fragments should be valid
(MD051, link-fragments)
[warning] 20-20: Link fragments should be valid
(MD051, link-fragments)
[warning] 21-21: Link fragments should be valid
(MD051, link-fragments)
[warning] 22-22: Link fragments should be valid
(MD051, link-fragments)
[warning] 23-23: Link fragments should be valid
(MD051, link-fragments)
[warning] 24-24: Link fragments should be valid
(MD051, link-fragments)
[warning] 25-25: Link fragments should be valid
(MD051, link-fragments)
[warning] 26-26: Link fragments should be valid
(MD051, link-fragments)
[warning] 27-27: Link fragments should be valid
(MD051, link-fragments)
[warning] 28-28: Link fragments should be valid
(MD051, link-fragments)
[warning] 29-29: Link fragments should be valid
(MD051, link-fragments)
[warning] 30-30: Link fragments should be valid
(MD051, link-fragments)
[warning] 31-31: Link fragments should be valid
(MD051, link-fragments)
[warning] 32-32: Link fragments should be valid
(MD051, link-fragments)
[warning] 33-33: Link fragments should be valid
(MD051, link-fragments)
[warning] 34-34: Link fragments should be valid
(MD051, link-fragments)
[warning] 35-35: Link fragments should be valid
(MD051, link-fragments)
[warning] 36-36: Link fragments should be valid
(MD051, link-fragments)
[warning] 183-183: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
[warning] 244-244: Blank line inside blockquote
(MD028, no-blanks-blockquote)
[warning] 383-383: Ordered list item prefix
Expected: 1; Actual: 3; Style: 1/1/1
(MD029, ol-prefix)
[warning] 398-398: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
[warning] 431-431: Ordered list item prefix
Expected: 1; Actual: 4; Style: 1/2/3
(MD029, ol-prefix)
[warning] 433-433: Ordered list item prefix
Expected: 2; Actual: 5; Style: 1/2/3
(MD029, ol-prefix)
[warning] 435-435: Ordered list item prefix
Expected: 3; Actual: 6; Style: 1/2/3
(MD029, ol-prefix)
[warning] 438-438: Ordered list item prefix
Expected: 1; Actual: 7; Style: 1/2/3
(MD029, ol-prefix)
[warning] 440-440: Ordered list item prefix
Expected: 2; Actual: 8; Style: 1/2/3
(MD029, ol-prefix)
[warning] 442-442: Ordered list item prefix
Expected: 3; Actual: 9; Style: 1/2/3
(MD029, ol-prefix)
[warning] 443-443: Spaces inside emphasis markers
(MD037, no-space-in-emphasis)
🔇 Additional comments (2)
docs/releasing.md (2)
201-205: Fix malformed markdown emphasis/code markers around resource names.Mixed markers like
`**ReleasePlan`**/**ReleasePlan** still appear and render inconsistently across the document.Also applies to: 251-254, 379-383, 398-399, 450-453, 498-499
407-407: Resolve conflicting 0.6.x branch guidance.Line 407 says 0.6.x micro releases follow
main, while the summary table states 0.6.1 commits are onrelease/0.6. Keep one canonical policy and reference it consistently.Also applies to: 450-451
| * [Konflux release organization](#release-organization) | ||
| * [Conventions](#conventions) | ||
| * [Goals of the layout](#1-goals-of-the-layout) | ||
| * [Konflux](#2-konflux) | ||
| * [Applications and components](#21-applications-and-components) | ||
| * [ReleasePlan per application and connection to RPA](#22-releaseplan-per-application-and-connection-to-rpa) | ||
| * [ReleasePlanAdmission (RPA)](#23-releaseplanadmission-rpa) | ||
| * [Comet (container catalog): what users pull](#3-comet-container-catalog-what-users-pull) | ||
| * [Lightspeed Stack](#31-lightspeed-stack) | ||
| * [Lightspeed RAG Tool (and compute flavors)](#32-lightspeed-rag-tool-and-compute-flavors) | ||
| * [How releases work in practice](#4-how-releases-work-in-practice) | ||
| * [Snapshot selection and creating a `Release` for an Application](#41-snapshot-selection-and-creating-a-release-for-an-application) | ||
| * [Micro releases (patch and RC)](#42-micro-releases-patch-and-rc) | ||
| * [Minor releases (new minor branch, e.g. 0.7)](#43-minor-releases-new-minor-branch-eg-07) | ||
| * [Checklists for release engineers](#5-checklists-for-release-engineers) | ||
| * [Micro release checklist (patch or RC)](#51-micro-release-checklist-patch-or-rc) | ||
| * [Minor release checklist (new minor branch)](#52-minor-release-checklist-new-minor-branch) | ||
| * [Invariants (check on every ship)](#53-invariants-check-on-every-ship) | ||
| * [Parallel publishing paths](#6-parallel-publishing-paths) |
There was a problem hiding this comment.
Fix broken TOC anchor fragments.
Several TOC links point to fragments that don’t match generated heading IDs (for example Line 18 links to #release-organization, while the heading at Line 178 generates a different anchor). This breaks in-page navigation.
Suggested TOC fix pattern
-* [Konflux release organization](`#release-organization`)
+* [Konflux release organization](`#konflux-release-organization`)Apply the same correction pattern to the nested entries so each fragment matches the exact heading text.
🧰 Tools
🪛 LanguageTool
[style] ~31-~31: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...atch-and-rc) * [Minor releases (new minor branch, e.g. 0.7)](#43-minor-releases-n...
(EN_ADJ_ORDER)
[style] ~34-~34: This is not the usual sequence for adjectives that have no special emphasis.
Context: ...rc) * [Minor release checklist (new minor branch)](#52-minor-release-checklist-ne...
(EN_ADJ_ORDER)
🪛 markdownlint-cli2 (0.22.1)
[warning] 18-18: Link fragments should be valid
(MD051, link-fragments)
[warning] 20-20: Link fragments should be valid
(MD051, link-fragments)
[warning] 21-21: Link fragments should be valid
(MD051, link-fragments)
[warning] 22-22: Link fragments should be valid
(MD051, link-fragments)
[warning] 23-23: Link fragments should be valid
(MD051, link-fragments)
[warning] 24-24: Link fragments should be valid
(MD051, link-fragments)
[warning] 25-25: Link fragments should be valid
(MD051, link-fragments)
[warning] 26-26: Link fragments should be valid
(MD051, link-fragments)
[warning] 27-27: Link fragments should be valid
(MD051, link-fragments)
[warning] 28-28: Link fragments should be valid
(MD051, link-fragments)
[warning] 29-29: Link fragments should be valid
(MD051, link-fragments)
[warning] 30-30: Link fragments should be valid
(MD051, link-fragments)
[warning] 31-31: Link fragments should be valid
(MD051, link-fragments)
[warning] 32-32: Link fragments should be valid
(MD051, link-fragments)
[warning] 33-33: Link fragments should be valid
(MD051, link-fragments)
[warning] 34-34: Link fragments should be valid
(MD051, link-fragments)
[warning] 35-35: Link fragments should be valid
(MD051, link-fragments)
[warning] 36-36: Link fragments should be valid
(MD051, link-fragments)
🤖 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/releasing.md` around lines 18 - 36, TOC anchor fragments are incorrect
and don’t match the generated heading IDs; update each TOC link so the fragment
exactly matches the markdown-generated slug for its heading (e.g., change the
top-level "`#release-organization`" to the slug for the actual heading "Konflux
release organization", update "Konflux" and nested items like "Applications and
components", "ReleasePlan per application and connection to RPA", and longer
headings such as "Comet (container catalog): what users pull" and "Snapshot
selection and creating a `Release` for an Application" to their exact generated
anchors), applying the same correction pattern to all nested entries so every
fragment equals the heading text’s slug (respecting lowercase,
punctuation/character removal, spaces -> hyphens rules).
| This section 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. | ||
|
|
||
|
|
||
| #### Conventions |
There was a problem hiding this comment.
Correct heading-level jump under Konflux section.
Line 183 uses #### Conventions directly under a ## section, which violates markdown heading hierarchy and contributes to TOC/anchor inconsistencies.
Proposed fix
-#### Conventions
+### Conventions🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 183-183: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(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/releasing.md` at line 183, The "Conventions" heading is incorrectly at
level #### directly under the "Konflux" (##) section; update the heading text
"Conventions" to use a single-step deeper level (### Conventions) to restore
proper markdown hierarchy and fix TOC/anchor issues, and then regenerate or
re-check the table of contents if your build process requires it.
2 participants
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