docs: merge changelog from master and release-* branches, fix condition for operatorhub pipeline

[AndrewChubatiuk]

fixes #2482

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="hack/merge_changelog.py">

<violation number="1" location="hack/merge_changelog.py:19">
P1: The changelog picker only parses one date format and scrambles the published CHANGELOG on the first merge. DATE_FORMAT is '%d %B %Y' (full month name), but the actual docs/CHANGELOG.md dates are mostly abbreviated months: recent entries use '04 August 2026' while 131 of 164 released versions use '12 Sep 2025', '17 Aug 2025', '26 Jul 2022', etc. Those fail strptime, so parse_release_date returns None and merge()'s sort (key=lambda v: v.date or datetime.min) sinks them to the very bottom with datetime.min. Because full- and abbreviated-month entries are interleaved (e.g. v0.25.0 '19 May 2022' is parseable while v0.26.0 '25 Jul 2022' is not), the re-sort no longer preserves reverse-chronological order: v0.63.0 (Sep 2025) would end up below v0.25.0 (May 2022), producing a badly ordered changelog on the operator docs site. Consider parsing both '%d %B %Y' and '%d %b %Y' (and single-digit days), or normalizing the changelog to a single format.</violation>
</file>

<sub>Tip: instead of fixing issues one by one fix them all with cubic

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: The changelog picker only parses one date format and scrambles the published CHANGELOG on the first merge. DATE_FORMAT is '%d %B %Y' (full month name), but the actual docs/CHANGELOG.md dates are mostly abbreviated months: recent entries use '04 August 2026' while 131 of 164 released versions use '12 Sep 2025', '17 Aug 2025', '26 Jul 2022', etc. Those fail strptime, so parse_release_date returns None and merge()'s sort (key=lambda v: v.date or datetime.min) sinks them to the very bottom with datetime.min. Because full- and abbreviated-month entries are interleaved (e.g. v0.25.0 '19 May 2022' is parseable while v0.26.0 '25 Jul 2022' is not), the re-sort no longer preserves reverse-chronological order: v0.63.0 (Sep 2025) would end up below v0.25.0 (May 2022), producing a badly ordered changelog on the operator docs site. Consider parsing both '%d %B %Y' and '%d %b %Y' (and single-digit days), or normalizing the changelog to a single format.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At hack/merge_changelog.py, line 19:

<comment>The changelog picker only parses one date format and scrambles the published CHANGELOG on the first merge. DATE_FORMAT is '%d %B %Y' (full month name), but the actual docs/CHANGELOG.md dates are mostly abbreviated months: recent entries use '04 August 2026' while 131 of 164 released versions use '12 Sep 2025', '17 Aug 2025', '26 Jul 2022', etc. Those fail strptime, so parse_release_date returns None and merge()'s sort (key=lambda v: v.date or datetime.min) sinks them to the very bottom with datetime.min. Because full- and abbreviated-month entries are interleaved (e.g. v0.25.0 '19 May 2022' is parseable while v0.26.0 '25 Jul 2022' is not), the re-sort no longer preserves reverse-chronological order: v0.63.0 (Sep 2025) would end up below v0.25.0 (May 2022), producing a badly ordered changelog on the operator docs site. Consider parsing both '%d %B %Y' and '%d %b %Y' (and single-digit days), or normalizing the changelog to a single format.</comment>

<file context>
@@ -0,0 +1,130 @@
+
+HEADING_RE = re.compile(r"^## .*$", re.MULTILINE)
+RELEASE_DATE_RE = re.compile(r"^\*\*Release date:\*\*\s*(.+)$", re.MULTILINE)
+DATE_FORMAT = "%d %B %Y"
+
+
</file context>

[AndrewChubatiuk]

addressed in both this PR and #2484